On Fri, 19 Sep 2014 09:08:46 +0200 Ludwig Krispenz <[email protected]> wrote:
> > On 09/18/2014 08:27 PM, Simo Sorce wrote: > > On Thu, 18 Sep 2014 14:22:07 -0400 > > Nathaniel McCallum <[email protected]> wrote: > > > >> On Thu, 2014-09-18 at 14:18 -0400, Simo Sorce wrote: > >>> On Thu, 18 Sep 2014 13:56:44 -0400 > >>> Nathaniel McCallum <[email protected]> wrote: > >>> > >>>> -objectClasses: (2.16.840.1.113730.3.8.16.2.2 NAME > >>>> 'ipatokenTOTP' SUP ipaToken STRUCTURAL DESC 'TOTP Token Type' > >>>> MUST (ipatokenOTPkey $ ipatokenOTPalgorithm $ ipatokenOTPdigits $ > >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep) MAY > >>>> (ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') +objectClasses: > >>>> (2.16.840.1.113730.3.8.16.2.2 NAME 'ipatokenTOTP' SUP ipaToken > >>>> STRUCTURAL DESC 'TOTP Token Type' MUST (ipatokenOTPkey $ > >>>> ipatokenOTPalgorithm $ ipatokenOTPdigits $ > >>>> ipatokenTOTPclockOffset $ ipatokenTOTPtimeStep $ > >>>> ipatokenTOTPwatermark) X-ORIGIN 'IPA OTP') > >>> NACK, you cannot move from MAY to MUST. > >> This is precisely what we have been discussing on IRC today. The > >> consensus was that this was acceptable because of the update plugin > >> and the rarity of the state in which a token would not have > >> ipatokenTOTPwatermark set (the token has to be created an never > >> used). > > Sorry I was not around, but it is never acceptable, as it may cause > > replication failures. > I agree that this shouldn't be done, although replication should not > be a problem, the consumer relies on the schema checking of the > server where the operation was originally applied. > But problems may show up for existing entries, if you have an an > entry without attr A, which now becomes MUST and then do any > modification on this entry, after the mod the entry will be schema > checked, the missing attribute detected and the mod rejected > > > > This has been a long (albeit perhaps unspoken) rule in changing > > schema in FreeIPA. > if you want to define the rules for schema change somewhere, you > should add this as well: never make a multivalued attribute > singlevalued Ok I added this new page: http://www.freeipa.org/page/Schema_Handling I would like to add a link to it in http://www.freeipa.org/page/Contribute/Code if I get a review and an ack for the page. > > > > Existing objectlasses can *never* gain new MUST attributes. This > > rule is rigid and is non-negotiable. > > If you want to ensure that every entry has a specific attribute, but > connot enforce this by the schema, an option would be to define a CoS > rule for this attr which defines a default and gives the real attr > precedence Yeah this is a good idea, should we add a section in that page with advice on how to handle situations where you'd like to change an objectclass/attribute but are not allowed by our rules ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
