OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6495
Full headers

From: kean.johnston@gmail.com
Subject: nssov patch to better emulate pam_ldap behaviour
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 22 Mar 2010 03:41:28 +0000
From: kean.johnston@gmail.com
To: openldap-its@OpenLDAP.org
Subject: nssov patch to better emulate pam_ldap behaviour
Full_Name: Kean Johnston
Version: HEAD
OS: Linux (CentOS 5.3)
URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch
Submission from: (NULL) (196.210.34.161)


The nssov manual page states that some of it's options "duplicates the original
pam_ldap authorization behavior". However, they don't quite. pam_ldap has the
ability for you to use "wildcards" in a user's host: attribute. I say
"wildcards" in quotes because the pam_ldap implementation does not actually use
regex matching, but rather check for two special strings, "*" and "!".

The ability to use actual wildcards, especially ones you can negate, on a per
user basis is extremely useful to an administrator of large networks. For
example you may want all developers to have access to the machines in
developers.mydomain.com but you want to disallow access to some of those
machines to contractors or interns.

This patch allows such behaviour, so it serves the dual purpose of actually
implementing existing pam_ldap behaviour in case people already depend on that,
as well as extends it to be a more generally usable feature by using actual
regular expressions. The code is simple, and the man page change describes it
well enough. Please consider adding this code to nssov. Thank you.

Followup 1

Download message
Date: Sun, 21 Mar 2010 22:51:52 -0500
From: Kean Johnston <kean.johnston@gmail.com>
To: openldap-its@openldap.org
CC: kean.johnston@gmail.com
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
ftp.openldap.org reports no space on the device, so the URL for the patch 
is at:

http://64.34.163.232/openldap/kean-johnston-100321.patch



Followup 2

Download message
Date: Sun, 21 Mar 2010 23:28:36 -0700
From: Howard Chu <hyc@symas.com>
To: kean.johnston@gmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
kean.johnston@gmail.com wrote:
> Full_Name: Kean Johnston
> Version: HEAD
> OS: Linux (CentOS 5.3)
> URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch
> Submission from: (NULL) (196.210.34.161)
>
>
> The nssov manual page states that some of it's options "duplicates the
original
> pam_ldap authorization behavior". However, they don't quite. pam_ldap has
the
> ability for you to use "wildcards" in a user's host: attribute. I say
> "wildcards" in quotes because the pam_ldap implementation does not actually
use
> regex matching, but rather check for two special strings, "*" and "!".
>
> The ability to use actual wildcards, especially ones you can negate, on a
per
> user basis is extremely useful to an administrator of large networks. For
> example you may want all developers to have access to the machines in
> developers.mydomain.com but you want to disallow access to some of those
> machines to contractors or interns.
>
> This patch allows such behaviour, so it serves the dual purpose of actually
> implementing existing pam_ldap behaviour in case people already depend on
that,
> as well as extends it to be a more generally usable feature by using actual
> regular expressions. The code is simple, and the man page change describes
it
> well enough. Please consider adding this code to nssov. Thank you.
>
Authorization is the job of the ACL engine. Putting ad-hoc rules into user 
entries is, in a word, stupid. It's also unscaleable and will become an 
administration nightmare.

The user host attribute functionality is deprecated. I have no desire to make 
it even vaguely appear to be useful.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 3

Download message
Date: Mon, 22 Mar 2010 07:40:45 -0500
From: Kean Johnston <kean.johnston@gmail.com>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
> Authorization is the job of the ACL engine. Putting ad-hoc rules into 
> user entries is, in a word, stupid. It's also unscaleable and will 
> become an administration nightmare.
Well OK then. Using a configuration mechanism like ACL's that cannot be 
distributed to multiple users (like editing a directory can) is, in a word, 
stupid. It is also unscaleable and will become an administration nightmare. 
And authorisation is not (or SHOULD not be) the job of ACL's its the job of 
authorisation modules, which nssov is.

Being forced to give admins who simply want to be able to change access to 
a random host in a centralised server root access to what may be a critical 
server with other sensitive data on it is simply wrong.

> The user host attribute functionality is deprecated. I have no desire to 
> make it even vaguely appear to be useful.
Then don't sell it as one. You claim pam_ldap compatibility but that is 
false. The user docs also aren't nearly as strongly worded, saying that the 
hostserver and ACL's is preferable, not that userhost is deprecated.

A flexible solution gives administrators the opportunity to use the tool in 
ways you haven't conceived of because it works for them and their 
environment. A ridgid and dictatorial tool forces people to do things one 
way and one way only. I have worked for one of the larger software 
companies and can tell you that the ACL mechanism would scale orders of 
magnitude worse, and they did, in fact have authorisation info stored in 
user and host attributes because that was the only way to delegate 
responsibility to multiple groups.

PS, you may wanna consider dropping the Ulrich Drepper attitude. When a 
contributor, especially a first time one, who has gone to considerable 
lengths to follow all the guidelines and do things just your way has, as 
his first experience someone calling things "stupid" ... well, that will 
thin the development herd considerably.



Followup 4

Download message
Date: Mon, 22 Mar 2010 06:26:13 -0700
From: Howard Chu <hyc@symas.com>
To: Kean Johnston <kean.johnston@gmail.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
Kean Johnston wrote:
>> Authorization is the job of the ACL engine. Putting ad-hoc rules into
>> user entries is, in a word, stupid. It's also unscaleable and will
>> become an administration nightmare.
> Well OK then. Using a configuration mechanism like ACL's that cannot be
> distributed to multiple users (like editing a directory can) is, in a word,
> stupid.  It is also unscaleable and will become an administration
nightmare.
> And authorisation is not (or SHOULD not be) the job of ACL's its the job of
> authorisation modules, which nssov is.
>
> Being forced to give admins who simply want to be able to change access to
> a random host in a centralised server root access to what may be a critical
> server with other sensitive data on it is simply wrong.

You seem to be laboring under the false premise that root privileges are 
required to administer authorization in slapd. Since that is false, the rest 
of your statements are moot.

>> The user host attribute functionality is deprecated. I have no desire
to
>> make it even vaguely appear to be useful.
> Then don't sell it as one. You claim pam_ldap compatibility but that is
> false. The user docs also aren't nearly as strongly worded, saying that the
> hostserver and ACL's is preferable, not that userhost is deprecated.

> A flexible solution gives administrators the opportunity to use the tool in
> ways you haven't conceived of because it works for them and their
> environment. A ridgid and dictatorial tool forces people to do things one
> way and one way only. I have worked for one of the larger software
> companies and can tell you that the ACL mechanism would scale orders of
> magnitude worse, and they did, in fact have authorisation info stored in
> user and host attributes because that was the only way to delegate
> responsibility to multiple groups.

That may have been true of that other software package. That is not true here.

> PS, you may wanna consider dropping the Ulrich Drepper attitude. When a
> contributor, especially a first time one, who has gone to considerable
> lengths to follow all the guidelines and do things just your way has, as
> his first experience someone calling things "stupid" ... well, that will
> thin the development herd considerably.

No, I should rather step it up a notch. I don't want contributions from J. 
Random Developer. I want contributions from people who participate in the 
community. That means reading up on how things are done, following the 
established practices, and demonstrating a familiarity with the way things are 
done and establishing a familiarity with the other community members. That 
means showing that you'll take the time to stick around and continue to 
maintain/support your code if we pull it in. If a developer won't put that 
time in up front, then I don't care how good their code is; I don't want to be 
saddled with it when they inevitably disappear.

The established practice for contributing new code is to discuss it on the 
openldap-devel mailing list first, before spending any time on actual coding. 
After the developer community gets a chance to think about it and weigh in on 
whether it's a good idea or not, then you start (or don't start) writing the 
code and submitting to the ITS.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 5

Download message
Date: Mon, 22 Mar 2010 21:00:58 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: kean.johnston@gmail.com, openldap-its@openldap.org
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
--On Monday, March 22, 2010 12:41 PM +0000 kean.johnston@gmail.com wrote:

>> Authorization is the job of the ACL engine. Putting ad-hoc rules into
>> user entries is, in a word, stupid. It's also unscaleable and will
>> become an administration nightmare.
> Well OK then. Using a configuration mechanism like ACL's that cannot be
> distributed to multiple users (like editing a directory can) is, in a
> word,  stupid. It is also unscaleable and will become an administration
> nightmare.  And authorisation is not (or SHOULD not be) the job of ACL's
> its the job of  authorisation modules, which nssov is.
>
> Being forced to give admins who simply want to be able to change access
> to  a random host in a centralised server root access to what may be a
> critical  server with other sensitive data on it is simply wrong.

As already noted, there is no need to give root access to admins.  My guess 
is you really do not understand how ACLs work.  I would advise carefully 
reading the slapd-access(5) man page.

Regards,
Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration



Followup 6

Download message
Date: Mon, 22 Mar 2010 22:43:53 -0700
From: Quanah Gibson-Mount <quanah@zimbra.com>
To: kean.johnston@gmail.com, openldap-its@openldap.org
Subject: Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
--On Monday, March 22, 2010 9:00 PM -0700 Quanah Gibson-Mount 
<quanah@zimbra.com> wrote:

> As already noted, there is no need to give root access to admins.  My
> guess is you really do not understand how ACLs work.  I would advise
> carefully reading the slapd-access(5) man page.

You may also find a page I wrote some time ago useful in helping to 
understand how ACLs work:

<http://www.stanford.edu/services/directory/openldap/configuration/slapd-acl.html>

Regards,
Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org