[Fedora-directory-devel] Please Review: Add LDAPI (LDAP over unix domain sockets)
by Pete Rowley
This is a feature that exists in OpenLDAP (but has no RFC that I am aware of).
Heimdal uses this feature exclusively for its directory interactions (making it
incompatible with other LDAP directories), and Samba testing is often performed
over unix domain sockets (a convenience for them). There are advantages: no TCP
overhead for local connections, the ability to test for the OS level user
credentials, and AFAIK, an unsniffable transport without additional
requirements. On that last point, I welcome arguments to the contrary.
The socket file is created as var/run/fedora-ds/slapd-<instance>.socket by
default, but this can be modified in configuration. I'm actually not sure where
the best place to put this is since access control along the path to the socket
matters. The socket itself is chmodded to give rw to owner, groups, and other by
the server upon creation.
I've added LDAPI auto authentication / bind, which basically means that if you
access the DS over LDAPI it will trust the OS level auth and automatically bind
you at connection open (i.e. the server won't wait for an explicit bind). There
are several options to this:
1. You can turn auto binding on or off
2. You can specify a dn that root should be bound as (e.g. directory manager, or
perhaps an admin account)
3. You can specify that the user maps to an existing entry via admin specified
attributes - which are probably going to be uidNumber and gidNumber (the
default) - root can be bound this way too, and this method takes precedence over 2.
4. In the event that the other methods are turned off, or do not result in bind
credentials, you can specify that a DN be constructed for the bind DN and supply
a suffix for the DN - this allows non-mapped entries to look sensible, you may
use this feature to specifiy a suffix that works with existing access control
for example.
When auto binding is on, and option 4. is set, or option 2. is set and the unix
user credentials match a single entry in the DIT, users are automatically bound
at connection open and anonymous binds are impossible since an anonymous bind
attempt is modified to the credentials used at connection open. Non-anonymous
binds work as usual. This means that scripts and so on can be "dumb" and
credentials need not be left lying around for snoopers, users on the local
machine not be concerned with credentials either, and yet all connections can be
subject to targetted access control.
All configuration is dynamically observed except for the socket file location
and the LDAPI switch itself - these require a server restart for the same
reasons TCP port modification does - the socket must be created with root
privilege prior to suing to its execution user.
Cross platform code for OS level authentication is currently defined out (other
than linux), I intend to enable that as testing for these platforms progresses.
Diff:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff
Additional files:
getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371
getsocketpeer.h: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148372
--
Pete
17 years, 1 month
[Fedora-directory-devel] 'make check' or 'make test' for fedora DS?
by Andrew Bartlett
Would it be possible to have some kind of self-test infrastructure in
Fedora DS?
I've grabbed current CVS, and am having some troubles running it. But I
can't tell if it's just the way I'm running it, or if the current codes
doesn't currently work on my machine.
What I would really like is for 'make check' to be more than a stub. As
fedora DS already depends on LDAP client bits, would it be too hard to
use the new ldapi:// work to setup fedora DS in a private environment,
and check a few things over (searches, binds, etc)?
This would also nicely solve some of the 'how do I' problems I have with
the ldapi:// patch (that is, it seems to still want an external port to
bind to, and I need to specify some details for the socket that
ds_newinst.pl doesn't know about).
We have had very good results with our 'make test' in Samba4, and
likewise I've seen Heimdal grow with it's testsuite (to the extent, that
Love's work has become almost entirely test driven development).
Naturally, it would also make it easier for external contributors to
validate their changes.
Thanks,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
17 years, 1 month
[Fedora-directory-devel] Please review: Bug 229691: Add enable switches for optional/experimental features
by Rich Megginson
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229691
Resolves: bug 229691
Bug Description: Add enable switches for optional/experimental features
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Added --enable-pam-passthru, --enable-dna, and
--enable-ldapi. They are all on by default and must be explicitly
disabled (--disable-pam-passthru). These all cause ENABLE_xxx to be
defined for C code so that we can enclose the code in #ifdef
ENABLE_PAM_PASSTHRU blocks, for example. For the first two, these also
cause the plugins to be built - so that if you specify
--disable-pam-passthru, the plugin code will not be built at all. I
discovered a nifty autoconf macro called AS_HELP_STRING - this nicely
formats the help messages output by configure --help. I don't know if
it's worth going through all of our m4 code to use this, but I went
ahead and fixed configure.ac. Create instance will now add plugin
configuration entries (but disabled) for pam passthru and dna if the
corresponding ENABLE_ macros are defined. I also fixed a bug with
passthru (not pam passthru) - the plugin configuration entry was not
being added.
Platforms tested: RHEL4, FC6
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148631&action=diff
17 years, 1 month
[Fedora-directory-devel] Commit: [Bug 229576] New: clean up template-scriptname which is derived from template-scriptname.in
by Noriko Hosoi
Summary: clean up template-scriptname which is derived from template-scriptname.in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229576
Summary: clean up template-scriptname which is derived from
template-scriptname.in
Product: Fedora Directory Server
Version: 1.0.4
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: normal
Component: Admin
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ohegarty(a)redhat.com
Estimated Hours: 0.0
The following files were removed from CVS. Please let me know if you find any problems caused by this change...
./ldap/admin/src/scripts/template-ldif2db.pl
./ldap/admin/src/scripts/template-db2bak
./ldap/admin/src/scripts/template-ns-activate.pl
./ldap/admin/src/scripts/template-vlvindex
./ldap/admin/src/scripts/template-verify-db.pl
./ldap/admin/src/scripts/template-ns-newpwpolicy.pl
./ldap/admin/src/scripts/template-ldif2db
./ldap/admin/src/scripts/template-ns-inactivate.pl
./ldap/admin/src/scripts/template-saveconfig
./ldap/admin/src/scripts/template-cl-dump.pl
./ldap/admin/src/scripts/template-restoreconfig
./ldap/admin/src/scripts/template-db2ldif
./ldap/admin/src/scripts/template-db2index
./ldap/admin/src/scripts/template-start-slapd
./ldap/admin/src/scripts/template-bak2db.pl
./ldap/admin/src/scripts/template-repl-monitor-cgi.pl
./ldap/admin/src/scripts/template-db2index.pl
./ldap/admin/src/scripts/template-bak2db
./ldap/admin/src/scripts/template-repl-monitor.pl
./ldap/admin/src/scripts/template-db2ldif.pl
./ldap/admin/src/scripts/template-ldif2ldap
./ldap/admin/src/scripts/template-db2bak.pl
./ldap/admin/src/scripts/template-suffix2instance
./ldap/admin/src/scripts/template-stop-slapd
./ldap/admin/src/scripts/template-ns-accountstatus.pl
./ldap/admin/src/scripts/template-monitor
./ldap/admin/src/ds_newinst.pl
------- Additional Comments From nhosoi(a)redhat.com 2007-02-21 16:19 EST -------
Created an attachment (id=148536)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148536&action=view)
email discussion
------- Additional Comments From nhosoi(a)redhat.com 2007-02-21 16:24 EST -------
Created an attachment (id=148538)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148538&action=view)
cvs commit message
Removed from CVS HEAD.
17 years, 1 month
[Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets)
by Howard Chu
> Date: Wed, 21 Feb 2007 09:34:03 -0700
> From: Richard Megginson <rmeggins(a)redhat.com>
>> Andrew Bartlett wrote:
>> > On Tue, 2007-02-20 at 17:07 -0800, Howard Chu wrote:
>>> >> I'd be a little concerned about this "auto bind". In OpenLDAP the credentials
>>> >> are only used if a SASL/EXTERNAL Bind is performed. In general I think it's
>>> >> poor policy to do something "magic" without a user actually requesting it.
>>> >> Especially where security is involved. Granted, a user could explicitly
>>> >> perform a Bind if they need to override the auto bind, but that's not the
>>> >> point. In typical LDAP use a session is anonymous until an explicit Bind has
>>> >> succeeded. IMO this behavior should be true regardless of the type of URL
>>> >> being used. E.g., with OpenLDAP right now, we can interchange ldap://,
>>> >> ldaps://, and ldapi:// URLs at will and apps see consistent behavior.
>> > I agree. Autobinding is a bad idea, as even for Samba I want that
>> > consistency: we run as root, but unless I start passing credentials,
>> > I'm expecting the DB to be giving me anonymous access.
> Is it possible that in some cases you would want the DS to use the OS
> credentials? In a sense, when I login to the OS with my
> username/password or other credentials, I am "bound" to my session, my
> identity has been validated.
Yes, this is precisely the use case for SASL/EXTERNAL, which is why we
implemented it that way.
> Also, for Heimdal, I thought one of the benefits of using ldapi was that
> you could have more privileged access to the LDAP data without having to
> store authentication credentials and use them as would be used when
> accessing over TCP.
Yes. But again, the Heimdal KDC does an explicit SASL/EXTERNAL Bind to
request this privilege. There is no assumption of automagic authorization.
Even though the credentials are available, the server will not inspect them
unless it receives a SASL/EXTERNAL Bind request. If it receives such a
request, then it will construct a SASL authentication DN of the form
gidNumber=GID+uidNumber=UID,cn=peercred,cn=external,cn=auth
which then drops into the usual SASL identity mapper for optional munging
into some other DN and that DN becomes the identity bound to the session.
Note that RFC4513 section 4 states explicitly :
Upon initial establishment of the LDAP session, the session has an
anonymous authorization identity.
Section 2 also states
LDAP server implementations MUST support the anonymous authentication
mechanism of the simple Bind method (Section 5.1.1).
I think it's clear that an anonymous bind MUST actually give you an anonymous
session state, not some other implicitly selected identity.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
17 years, 1 month
[Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets)
by Howard Chu
> Date: Mon, 19 Feb 2007 14:08:16 -0800
> From: Pete Rowley <prowley(a)redhat.com>
> This is a feature that exists in OpenLDAP (but has no RFC that I am aware of).
I don't remember when/where this feature originated. Checking CVS I see that
Luke Howard did the initial commit, 2000-01-02. I'd guess it was part of his
early work on XAD. Originally we didn't use getpeereid, and just relied on
socket permissions for access control. We added getpeereid in 2002, first on
Linux and then Solaris and other platforms followed.
> Heimdal uses this feature exclusively for its directory interactions (making it
> incompatible with other LDAP directories),
Luke also wrote that part of Heimdal, no surprise there...
> and Samba testing is often performed
> over unix domain sockets (a convenience for them).
...
> There are advantages: no TCP
> overhead for local connections, the ability to test for the OS level user
> credentials, and AFAIK, an unsniffable transport without additional
> requirements. On that last point, I welcome arguments to the contrary.
It's possible, if you have privileges to insert kernel modules. But I think
that's for someone else to worry about, not in scope here. (I.e., if you have
someone malicious who can do that, you've already lost the machine.)
> The socket file is created as var/run/fedora-ds/slapd-<instance>.socket by
> default, but this can be modified in configuration. I'm actually not sure where
> the best place to put this is since access control along the path to the socket
> matters. The socket itself is chmodded to give rw to owner, groups, and other by
> the server upon creation.
> I've added LDAPI auto authentication / bind, which basically means that if you
> access the DS over LDAPI it will trust the OS level auth and automatically bind
> you at connection open (i.e. the server won't wait for an explicit bind). There
> are several options to this:
I'd be a little concerned about this "auto bind". In OpenLDAP the credentials
are only used if a SASL/EXTERNAL Bind is performed. In general I think it's
poor policy to do something "magic" without a user actually requesting it.
Especially where security is involved. Granted, a user could explicitly
perform a Bind if they need to override the auto bind, but that's not the
point. In typical LDAP use a session is anonymous until an explicit Bind has
succeeded. IMO this behavior should be true regardless of the type of URL
being used. E.g., with OpenLDAP right now, we can interchange ldap://,
ldaps://, and ldapi:// URLs at will and apps see consistent behavior.
> When auto binding is on, and option 4. is set, or option 2. is set and the unix
> user credentials match a single entry in the DIT, users are automatically bound
> at connection open and anonymous binds are impossible since an anonymous bind
> attempt is modified to the credentials used at connection open.
As above, changing the semantics of anonymous Bind is a bad idea.
> All configuration is dynamically observed except for the socket file location
> and the LDAPI switch itself - these require a server restart for the same
> reasons TCP port modification does - the socket must be created with root
> privilege prior to suing to its execution user.
> Cross platform code for OS level authentication is currently defined out (other
> than linux), I intend to enable that as testing for these platforms progresses.
>
> Diff:
>
> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148370&action=diff
>
> Additional files:
>
> getsocketpeer.c: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148371
As noted in OpenLDAP's implementation, using MSG_PEEK will fail on AIX. But I
guess you can worry about that when you actually have the code base ported to
AIX... You might consider using the same API/name as OpenLDAP does, for
source code compatibility, even though this isn't a function apps need to
call themselves. (I.e., I can't think of a need for it at the moment, but one
may spring up down the road.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
17 years, 1 month
[Fedora-directory-devel] Re: Please Review: Add LDAPI (LDAP over unix domain sockets)
by Howard Chu
> Date: Mon, 19 Feb 2007 14:08:16 -0800
> From: Pete Rowley <prowley(a)redhat.com>
> This is a feature that exists in OpenLDAP (but has no RFC that I am aware of).
> Heimdal uses this feature exclusively for its directory interactions (making it
> incompatible with other LDAP directories), and Samba testing is often performed
> over unix domain sockets (a convenience for them). There are advantages: no TCP
> overhead for local connections
This turns out to be pretty significant too - using TCP connections to
localhost, a connection soak test will use up all available port numbers in a
matter of seconds, after which all connection attempts fail. (Because there
is a mandatory 2MSL timeout before a closed port may be made available for
reuse.) Using ldapi we can process thousands of connections per second
indefinitely. (Perhaps someone ought to suggest to the kernel folks that a
2MSL timeout on loopback sockets is unnecessary, since presumably the TCP
close handshake can't get misrouted/lost there. ;)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
17 years, 1 month
[Fedora-directory-devel] Please Review: (229428) ns-slapd not linking to C++ runtime on HP-UX
by Nathan Kinder
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229428
Resolves: bug 229428
Bug Description: While testing the binaries from the autotools based
build on HP-UX,
I was unable to get ns-slapd to run due to an unresolved symbol. I
was seeing the
following errors in the errors log:
error:[20/Feb/2007:10:31:55 -0800] - Netscape Portable Runtime error
-5977:
Unsatisfied data symbol '_ZTVN10__cxxabiv120__si_class_type_infoE'
in load
module '//opt/fedora-ds/lib/libicui18n.so.34'.
On HP-UX, the program that contains the main() function must be
linked with the
C++ compiler (aCC -AA in our case) if it loads any C++ shared libraries.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: Tell libtool to use CXXLINK for linking ns-slapd on HP-UX.
Platforms tested: HP-UX 11.23 ia64
Flag Day: no
Doc impact: no
QA impact: should be covered by regular nightly and manual testing
New Tests integrated into TET: none
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=148457
17 years, 1 month