Andrew Bartlett wrote:
On Wed, 2006-11-01 at 07:05 -0700, Richard Megginson wrote:
Andrew Bartlett wrote:
On Tue, 2006-10-31 at 21:05 -0700, David Boreham wrote:
Andrew Bartlett wrote:
Does anybody have any pointers to an existing feature request like this,
or should I file one in Bugzilla?
This is what is implemented :
http://www.redhat.com/docs/manuals/dir-server/ag/7.1/acl.html#1216899
That has:
Information is not given for attributes in an entry that do not have a
value; for example, if the userPassword value is removed, then a
future effective rights search on the entry above would not return any
effective rights for userPassword, even though self-write and
self-delete rights could be allowed. Likewise, if the street attribute
were added with read, compare, and search rights, then street: rsc
would appear in the attributeLevelRights results.
I need information on unknown attributes, so that MMC can show them as
valid, writable fields (not greyed out). My preferred format is a list
of writable fields, as permitted by the current schema for that entry.
This could be useful in any general purpose GUI app, to have the ability
to perform one query and get back a list of
1) regular attributes available according to the schema
2) operational attributes - writable vs. read-only
3) virtual attributes - writable vs. read-only
I would like to support the openldap "+" special attribute which
retrieves all operational attributes, and I would also like to support
the Sun DS real and virtual attrs controls.
Andrew, I think it would be beneficial to me if you could post an
example ldapsearch and an example return entry in LDIF.
Using Samba's ldbsearch:
bin/ldbsearch -H ldap://win2k3dc.win2k3.abartlet.net cn=administrator
allowedAttributes allowedAttributesEffective allowedClasses
AllowedClassesEffective -Uadministrator%penguin
What's the -U for? My guess is -U<user>%<cred>, is it correct?
allowedAttributesEffective: adminDisplayName
What identity does the "Effective" refer to? That of the client
performing the request? How would this deal with ACL that depend on the
value of the data? How would this deal with ACLs that do not just
depend on the object and on the client's identity?
Moreover, I believe this type of operation should be itself protected by
ACLs, i.e. implementations should be able to restrict identities that
can get this info. With an ACL model that accounts for attribute values
(like any serious implementation should provide), the list itself could
be incomplete if access to specific values of allowedAttributes or
allowedAttributesEffective is itself restricted.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@xxxxxxxxxx
------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
