[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: rename permission
David,
Thanks for teasing out all the cases--that helps understanding of what it
means to grant rename in the modifyDN operation
I think the reason we felt it would be acceptable to let "n" imply the
"o" and "w" permissions on the affected attributes was that we felt that
the rename permission was was special enough to allow this--I would
venture that it's mostly granted to only a few, pretty well trusted users
(ie. can be trusted not to fool around with their "w" and "o" implied
permissions). Also, there is schema checking which should help stop truly
bizzarre attributes showing up as the rdn.
However, although this kind of "permission implication" simplifies the
spec I think it's big drawback is that it introduces a kind of side effect
that makes it harder at aci configure time to understand exactly what
policy it is that you have configured. For example, you might think you
have locked down access to the sn attribute by carefully controlling the
"o" and "w" permissions to it, but you need to remember that an aci that
grants "n" to an entry could also grant "o" and "w" type access to the
sn attribute of that entry.
So, I think your suggestion of also checking "o" and "w" permissions on
this operation is good.
There is one other operation where this kind of
"implication" occurs--it's the Delete operation (section 5.5). We take
"d" on an entry as implying "o" on all the attributes of that entry.
Given the above this kind of needles me though I think the getout is that
the Delete operation is alot more straightforward than the modifyDN
operation. So that when an admin sees "d" on an entry, he will probably
not be surprised that this grants "o" on all the attributes of the entry.
Rob.
David Chadwick wrote:
> Ellen and co
>
> there are many different variants of the ModifyDN operation, and
> you have only captured some of them in your text in section 5.6.
> Specifically one can
>
> i) Rename an entry by moving the conceptual RDN flag between
> two existing attribute values, without altering any attribute values at
> all
>
> ii) rename an entry by adding a new attribute value
>
> iii) rename an entry using an existing attribute value and delete the
> current attribute value
>
> iv) rename an entry adding a new attribute value and deleting the
> current attribute value
>
> v) move an entry to a new place in the DIT, keeping its existing
> RDN as is
>
> vi) move an entry to a new place coupled with i) above
> vii) move coupled with ii) above
> viii) move coupled with iii) above
> ix) move coupled with iv) above
>
> Now we already have all the component permissions for each of the
> above, in the write, obliterate, import, export and renameDN
> permissions. We use write and obliterate when adding and deleting
> attribute values with the Modify operation. To be consistent with the
> Modify operation, this would mean that permissions for ModifyDN
> would become
>
> i) needs renameDN only
> ii) needs renameDN and write
> iii) needs renameDN and obliterate
> iv) needs renameDN, write and obliterate
> v) needs import and export
> vi) needs import, export and renameDN
> vii) needs import, export, renameDN and write
> viii) needs import, export, renameDN and obliterate
> ix) needs import, export, renameDN, write and obliterate
>
> This seems sensible to me, as each permission keeps its logical
> meaning, and it should make it a lot easier to explain the operation
> as no special cases then exist. I think your NoteB is slightly
> spurious, since renameDN clearly gives ModifyDN permission and
> without it you cannot effect a change of DN (other than to import
> and export). renameDN does not effect Modify operation
> permission. Also when you give o and w (Modify) permission you
> give it to attributes, not to the entire entry. Therefore if you do not
> want someone to have Modify permission but you want them to
> have only ModifyDN permission with the scheme above you can
> give them precisely how much DN modification you want. I contend
> that if you are happy to allow someone to modify a RDN, you must
> be happy for them to update (modify) the attribute(s) comprising the
> RDN (its illogical to say otherwise). Further, with the scheme as it
> stands RenameDN is given to the whole entry, without limiting
> attribute types, so you have no means of controlling how much or
> little renaming they can do. They could for instance change the RDN
> from CN=Ellen Stokes to TelNo=1234, and the access controls as
> they stand cannot stop this. With the proposed scheme above they
> can.
>
> Comments?
>
> David
>
> ***************************************************
>
> David Chadwick
> IS Institute, University of Salford, Salford M5 4WT
> Tel +44 161 295 5351 Fax +44 161 745 8169
> Mobile +44 790 167 0359
> Email D.W.Chadwick@salford.ac.uk
> Home Page http://www.salford.ac.uk/its024/chadwick.htm
> Understanding X.500 http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string MLJ9-DU5T-HV8J
>
> ***************************************************