Hi,
Summary: is it possible to configure access control such that users to can add, but not delete, entries?
Details:
My planned schema has a branch:
ou=tags,dc=example,dc=com
The entries below this are like this:
objectClass=groupOfNames cn=sometagname member=<user dn 1> member=<user dn 2> member=<user dn 3> ...
I have worked out how to make it so users can only add and remove themselves from a tag:
access to dn.children="ou=tags,dc=example,dc=com" attrs=member,entry # Allow people to add and remove themselves from any other tag by dnattr=member selfwrite # Allow anyone to read by anonymous read
So far so good, but I would like authenticated users to be able to add new entries (tags), and add themselves as members to them, but _not_ to be able to delete tags.
Even better, the tag would be deletable, or even automatically removed, but only if the user removed their own name and there were no more members - i.e. it was empty. (I believe the member attribute is mandatory in groupOfNames, and I don't want it to be impossible for someone to remove their name because they are the only member!)
This is difficult, because as far as I can see the "write" permission does not distinguish between adding and deleting.
Can someone tell me if this is possible?
Thanks,
Gerv
Gervase Markham wrote:
Hi,
Summary: is it possible to configure access control such that users to can add, but not delete, entries?
This is difficult, because as far as I can see the "write" permission does not distinguish between adding and deleting.
Can someone tell me if this is possible?
Sounds to me like you haven't read the slapd.access(5) manpage.
The answer is "yes." Read the section on "THE <ACCESS> FIELD" in the manpage.
On 03/03/11 13:49, Howard Chu wrote:
Sounds to me like you haven't read the slapd.access(5) manpage.
You are quite right. I read this: http://www.openldap.org/doc/admin24/access-control.html
In particular, http://www.openldap.org/doc/admin24/access-control.html#The%20access%20to%20... seems not to be as detailed as the man page you pointed me to. It contains most, but not all, the possible values and "add" and "delete" are both missing.
Is this documentation incomplete, or is the answer elsewhere in the Administrator's Guide?
The answer is "yes." Read the section on "THE <ACCESS> FIELD" in the manpage.
Thank you :-)
Gerv
Gervase Markham wrote:
On 03/03/11 13:49, Howard Chu wrote:
Sounds to me like you haven't read the slapd.access(5) manpage.
You are quite right. I read this: http://www.openldap.org/doc/admin24/access-control.html
In particular, http://www.openldap.org/doc/admin24/access-control.html#The%20access%20to%20... seems not to be as detailed as the man page you pointed me to. It contains most, but not all, the possible values and "add" and "delete" are both missing.
Is this documentation incomplete, or is the answer elsewhere in the Administrator's Guide?
Note that a "Guide" is not a reference manual; it is not intended to be complete or exhaustive. It's only intended to provide an overview; the detailed/exhaustive docs are always the manpages.
On 03/03/11 15:33, Howard Chu wrote:
Note that a "Guide" is not a reference manual; it is not intended to be complete or exhaustive.
I'm not sure this use of terminology is universal; here is a counter-example: http://www.bugzilla.org/docs/tip/en/html/
It's only intended to provide an overview; the detailed/exhaustive docs are always the manpages.
I would suggest that neither: http://www.openldap.org/doc/ nor http://www.openldap.org/doc/admin24/preface.html nor the individual pages in the Admin Guide give the impression either that the Admin Guide is not complete, or that the manual pages are an essential read or the canonical reference.
Perhaps it would help OpenLDAP users if this were made a little more clear?
Thank you for your help and support :-)
Gerv
Gervase Markham wrote:
On 03/03/11 15:33, Howard Chu wrote:
Note that a "Guide" is not a reference manual; it is not intended to be complete or exhaustive.
I'm not sure this use of terminology is universal; here is a counter-example: http://www.bugzilla.org/docs/tip/en/html/
It's certainly been the norm for Unix at least. E.g., compare the Guides vs Reference Manuals in the Solaris documentation.
http://download.oracle.com/docs/cd/E19253-01/index.html
Or the 4BSD system documentation:
http://www.freebsd.org/doc/en/books/faq/bibliography.html
Material in the 4BSD User's Supplementary Documents and Programmer's Supplementary Documents was a bit more friendly in prose, but only explained the approach to how to use the system. The details of each command or function are only found in the Reference Manuals.
It's only intended to provide an overview; the detailed/exhaustive docs are always the manpages.
I would suggest that neither: http://www.openldap.org/doc/ nor http://www.openldap.org/doc/admin24/preface.html nor the individual pages in the Admin Guide give the impression either that the Admin Guide is not complete, or that the manual pages are an essential read or the canonical reference.
Perhaps it would help OpenLDAP users if this were made a little more clear?
The preface.html which you linked above clearly states:
Scope of this Document
This document provides a guide for installing OpenLDAP Software 2.4 (http://www.openldap.org/software/) on UNIX (and UNIX-like) systems. The document is aimed at experienced system administrators with basic understanding of LDAP-based directory services.
This document is meant to be used in conjunction with other OpenLDAP information resources provided with the software package and on the project's site (http://www.OpenLDAP.org/) on the World Wide Web. The site makes available a number of resources.
... <<<<
And then goes on to list various other resources. The Manual Pages, of course are the most obvious information resource provided directly with the software, and in Unix they are traditionally the authoritative reference. Given the heritage of this project it seems obvious to me that this is how the docs would be structured. If the phrase "meant to be used in conjunction" isn't a strong enough hint that the Guide is not a standalone document, please feel free to suggest an alternate or stronger wording. Note that the preface also invites you to do the same.
Thank you for your help and support :-)
Thank you for your feedback. We're always listening.
On 03/03/11 16:12, Howard Chu wrote:
The preface.html which you linked above clearly states:
Scope of this Document
This document provides a guide for installing OpenLDAP Software 2.4 (http://www.openldap.org/software/) on UNIX (and UNIX-like) systems. The document is aimed at experienced system administrators with basic understanding of LDAP-based directory services.
This document is meant to be used in conjunction with other OpenLDAP information resources provided with the software package and on the project's site (http://www.OpenLDAP.org/) on the World Wide Web. The site makes available a number of resources.
... <<<<
And then goes on to list various other resources.
A list of 7 resources, including the mailing lists and the issue tracking system. I assume reading all of those is not required?
The Manual Pages, of course are the most obvious information resource provided directly with the software, and in Unix they are traditionally the authoritative reference.
Well, not for the GNU project, at least (which supplies large chunks of the most popular modern Unix):
"In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. It’s your choice whether to include a man page in your program."
http://www.gnu.org/prep/standards/standards.html#Man-Pages
It then goes on to discourage GNU authors from bothering with man pages.
Given the heritage of this project it seems obvious to me that this is how the docs would be structured.
That sounds as if you are saying that familiarity with the heritage of the project is necessary in order to work out how to use the software.
If the phrase "meant to be used in conjunction" isn't a strong enough hint that the Guide is not a standalone document, please feel free to suggest an alternate or stronger wording. Note that the preface also invites you to do the same.
I would say instead:
This document is not a complete guide to its subject matter; the man pages are the definitive documentation for OpenLDAP software. Specifically, the following man pages:
OpenLDAP API:
<ul> <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> </ul>
OpenLDAP configuration:
<ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.conf">slapd.conf(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd-config">slapd-config(5)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapd.access">slapd.access(5)</a> </ul>
OpenLDAP command line tools:
<ul> <li><a href="http://www.openldap.org/software/man.cgi?query=slapacl">slapacl(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapadd">slapadd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapauth">slapauth(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapcat">slapcat(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapdn">slapdn(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapindex">slapindex(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slappasswd">slappasswd(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slapschema">slapschema(8)</a> <li><a href="http://www.openldap.org/software/man.cgi?query=slaptest">slaptest(8) </ul>
And then, for particularly relevant man pages, such as slapd.access for the Access section, I would put another link on the relevant page of the Guide.
Gerv
Gervase Markham wrote:
On 03/03/11 16:12, Howard Chu wrote:
The preface.html which you linked above clearly states:
Scope of this Document
This document provides a guide for installing OpenLDAP Software 2.4 (http://www.openldap.org/software/) on UNIX (and UNIX-like) systems. The document is aimed at experienced system administrators with basic understanding of LDAP-based directory services.
This document is meant to be used in conjunction with other OpenLDAP information resources provided with the software package and on the project's site (http://www.OpenLDAP.org/) on the World Wide Web. The site makes available a number of resources.
... <<<<
And then goes on to list various other resources.
A list of 7 resources, including the mailing lists and the issue tracking system. I assume reading all of those is not required?
Point taken. Though I would say familiarity with all of them is needed when you run into a problem that isn't addressed in the formal docs.
The Manual Pages, of course are the most obvious information resource provided directly with the software, and in Unix they are traditionally the authoritative reference.
Well, not for the GNU project, at least (which supplies large chunks of the most popular modern Unix):
GNU is Not Unix.
"In the GNU project, man pages are secondary. It is not necessary or expected for every GNU program to have a man page, but some of them do. It’s your choice whether to include a man page in your program."
http://www.gnu.org/prep/standards/standards.html#Man-Pages
It then goes on to discourage GNU authors from bothering with man pages.
Interesting reference. A couple of comments 1) They specifically need to call out this point, because they clearly are going against established practice in making this point. 2) As much as I am a supporter of the GNU project, not all of their policies actually make sense. E.g., the recommended viewer for their docs is Emacs. Their philosophy has been "since memory is now plentiful and cheap on computers, it's OK to use as much as you want without any second thought" since the late 1980s. I dunno about you, but I run OpenLDAP on my Android G1 phone, and I *don't* run emacs or tex on it. Bytes of RAM and individual CPU cycles are still scarce resources in the real world.
Given the heritage of this project it seems obvious to me that this is how the docs would be structured.
That sounds as if you are saying that familiarity with the heritage of the project is necessary in order to work out how to use the software.
Not at all, I was merely giving a counter-example to yours, showing that there's a method to this madness and it is in fact a time-honored one.
Frankly, anybody who has been to school in the past century should recognize it, because it's the standard model for educational texts. Just like a handbook on (e.g. English) grammar is not a complete reference to a language - it's simply a guide that gives the rules on how atoms fit together. It gives examples on how sentences are constructed but that's by no means a statement that those examples are the only possible sentences. There are dictionaries to provide more complete references to all the available atoms, and you are expected to construct your own sentences using the combination of those rules and those available atoms.
If the phrase "meant to be used in conjunction" isn't a strong enough hint that the Guide is not a standalone document, please feel free to suggest an alternate or stronger wording. Note that the preface also invites you to do the same.
I would say instead:
This document is not a complete guide to its subject matter; the man pages are the definitive documentation for OpenLDAP software.
Fair enough. But again, as the preface states, suggestions/changes should be posted to the ITS so that they may be tracked.
Specifically, the following man pages:
OpenLDAP API:
<ul> <li><a href="http://www.openldap.org/software/man.cgi?query=ldap">ldap(3)</a> </ul>
We'll have to think about how to integrate these hyperlinks into the Guide. IMO we should not be encouraging people to rely on the web as their first source of information; their first source of information should always be the man pages that are already installed on their own hard drives. The reasons being
1) the manpages on their machine will most likely match the release of the code that's actually running on their machine. We see a lot of problems from people who read current documentation on the web site but they're in fact running a 5-6 year old release that their distro provided, and they wonder why some feature they tried to use didn't work (wasn't there). (We also occasionally get the opposite, someone followed a link from an outdated HOWTO to an old version of the Guide, tho they are running current code.) 2) relying on a remote server for documentation is dicy at best, especially when you're in the middle of a disaster and you need the info Right Now and your network has failed.
We could provide HTML-formatted copies of the manpages in the Guide but IMO that's a waste of space.
And then, for particularly relevant man pages, such as slapd.access for the Access section, I would put another link on the relevant page of the Guide.
There already are multiple references to slapd.access in the Access Control chapter, but I've added another at the top of the chapter as a result of this conversation.
Gervase Markham wrote:
Hi,
Summary: is it possible to configure access control such that users to can add, but not delete, entries?
Yes, see "add" level (cfr.. "a" permission) in slapd.access(5).
p.
Details:
My planned schema has a branch:
ou=tags,dc=example,dc=com
The entries below this are like this:
objectClass=groupOfNames cn=sometagname member=<user dn 1> member=<user dn 2> member=<user dn 3> ...
I have worked out how to make it so users can only add and remove themselves from a tag:
access to dn.children="ou=tags,dc=example,dc=com" attrs=member,entry # Allow people to add and remove themselves from any other tag by dnattr=member selfwrite # Allow anyone to read by anonymous read
So far so good, but I would like authenticated users to be able to add new entries (tags), and add themselves as members to them, but _not_ to be able to delete tags.
Even better, the tag would be deletable, or even automatically removed, but only if the user removed their own name and there were no more members - i.e. it was empty. (I believe the member attribute is mandatory in groupOfNames, and I don't want it to be impossible for someone to remove their name because they are the only member!)
This is difficult, because as far as I can see the "write" permission does not distinguish between adding and deleting.
Can someone tell me if this is possible?
Thanks,
Gerv
Am Thu, 03 Mar 2011 13:30:09 +0000 schrieb Gervase Markham gerv@mozilla.org:
Hi,
Summary: is it possible to configure access control such that users to can add, but not delete, entries?
Details:
My planned schema has a branch:
ou=tags,dc=example,dc=com
The entries below this are like this:
objectClass=groupOfNames cn=sometagname member=<user dn 1> member=<user dn 2> member=<user dn 3> ...
I have worked out how to make it so users can only add and remove themselves from a tag:
access to dn.children="ou=tags,dc=example,dc=com" attrs=member,entry # Allow people to add and remove themselves from any other tag by dnattr=member selfwrite # Allow anyone to read by anonymous read
So far so good, but I would like authenticated users to be able to add new entries (tags), and add themselves as members to them, but _not_ to be able to delete tags.
Even better, the tag would be deletable, or even automatically removed, but only if the user removed their own name and there were no more members - i.e. it was empty. (I believe the member attribute is mandatory in groupOfNames, and I don't want it to be impossible for someone to remove their name because they are the only member!)
This is difficult, because as far as I can see the "write" permission does not distinguish between adding and deleting.
Can someone tell me if this is possible?
Yes this is possible, man slapd.access(5) in particular read on privileges, as an example: access to foo by foobar =ar
-Dieter
openldap-technical@openldap.org
-
Dieter Kluenter -
Gervase Markham -
Howard Chu -
Pierangelo Masarati