Hello Mohacsi,
Dear All,
I think there is a some architectural issues with the current
implementation of nsswitch or nsdispatch(3).
Let's assume you want to authenticate against an LDAP database. You will
install nss_ldap from port. You configure nss_ldap.conf with binddn and
its bindpw. Here comes the problem:
1. If permission of nss_ldap.conf is 0400 since it contains the clear
text password of the binddn, then an ordinary user cannot bind to the
database and cannot get UID->name information from LDAP database. See
output:
[EMAIL PROTECTED]> ls -l /home
total 6
drwxr-xr-x 3 9027 wheel 512 May 23 17:57 user1
drwxrwxr-x 3 root 9030 512 May 23 15:14 documents
drwxr-xr-x 2 9013 9013 512 May 23 15:13 user2
....
This does not pose problem for programs with root credentials since they
can access to LDAP database since they can fetch the password...
2. If you set the permission of nss_ldap.conf to 0444 then, you can access
to the LDAP UID database:
[EMAIL PROTECTED]> ls -l /home
total 6
drwxr-xr-x 3 user1 wheel 512 May 23 17:57 user1
drwxrwxr-x 3 root docs 512 May 23 15:14 documents
drwxr-xr-x 2 user2 user2 512 May 23 15:13 user2
....
However it can generate some security problems since everybody can
access to bindpw and potentially the whole LDAP database.
The problem, that you've described seems to be typical for nss_ldap users.
I think some kind of solution would be to use nscd or cached (from
FreeBSD 7.0) since nscd/cached could be run with root credential (and
use 0400) of nss_ldap.conf. And normal users would access via
nsdispatch(3) with their own credential.
Yes - this is a solution.
Other solution(?) would be to limit binddn access to read-only (also
limiting access only few attributes in LDAP) then exposing the bindpw
would not create big problem. However maintenance of LDAP ACI-s could be
difficult: nss_ldap attribute mapping and attribute usage should be
documented....
I think, that limiting binddn access to readonly is the best practice
whether you use nscd/cached or not. BTW, what kind of documentation do
you need? I can possibly provide the necessary information.
Do you think that cached(8) can be MFC-ed to RELENG_6 from current? Any
alternative solution? Maybe in the ports tree?
The thing is cached(8) requires a lot of changes to libc to be made. So
the ports tree is not the solution here. This is also a reason why it's
MFCing to RELENG_6 is questionable.
There is a lookupd (sysutils/lookupd) daemon in ports, which can be
plugged into existing nsswitch implementation and function similar to
cached/nscd - but it's quite out of date.
Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
With best regards,
Michael Bushkov
Southern Federal University
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
