On Fri, Apr 04, 2008 at 11:34:38PM +0200, Arthur de Jong wrote: > > On Sun, 2008-03-30 at 07:17 +1100, Alex Samad wrote: > > > That would be a solution but not something I would want to > > > implement. If it were some sort of search already I could add it but > > > since this is an attribute lookup like any other. > > > > shouldn't be that hard to do, from my limit knowledge of looking at > > the code, I guess at that point you already have the dn, it should be > > a simple as search for (&(dn=<cached dn>)(objectclass=<value you are > > looking for>)), if you get back 1 object (or more ??) then true else > > false > > It starts a full new search for an attribute lookup which is a bit ugly. > Also, the added value of this is close to zero because if you don't > allow lookups of objectClass you're bound to not allow lookups of > userPassword (the only reason the objectClass is queried). Since the strange I don't allow allow access to userPassword.
The way that I was getting this error when I was trying to enumerate through the group a user id had id id -G id <user> would give different results. > warning is gone now I would leave it at that (unless you can come with > good arguments). > No really good arguments apart from the fact that you need read access to objectclass. I haven't checked if there is a possibility that a userid could change objectclasses whilst still being cached by the niss-ldap code. > > > By the way, is there any specific reason why you don't want to allow > > > lookups of objectClass of any entries? > > > > gives you access to which groups are available, for example you could > > find out all the different group names that are available > > I don't understand this. Also this is what NSS does with 'getent group'. > If you use objectClass for some sort of ACLs I could imagine something > though. Some site where I have been to dissallow access to the objectClass attribute and they have sited security as the reason, no reason to give every access to what groups are available. Before changing over to nss-ldap I did not have a problem with this. Seems reasonable. My current solution is to limit it to the proxy account. The only reason (as pointed out above) not to do a ldapsearch and use the result to test if it exists, is to save on the overhead of the ldap call. I thought it did a search based on objectClass=posixgroup and then read the cn value back, which doesn't mean it needs read access to objectclass > > -- > -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong -- -- Life is a sexually transmitted disease.
signature.asc
Description: Digital signature
