[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fresh blood gets congested: long way to become DD

Hash: SHA1

Steve Langasek skrev:
> On Tue, Aug 02, 2005 at 03:01:39PM +0200, Tomas Fasth wrote:
>> Andreas Barth skrev:
>>> * Thijs Kinkhorst (kink@squirrelmail.org) [050802 13:41]:
>>>> And even then, appearently the DAM works like this: I
>>>> approve person X, let's check his box, but I'll add the
>>>> account at some point later on (this takes weeks on
>>>> average). When you check the box you might add the account 
>>>> aswell when you're at it, right?
>>> Just that the person who checks the reports is not root in
>>> Debian's ldap system.
>> There is delegation and group access available in OpenLDAP. So,
>> one would not need to have write access to the whole directory
>> tree, only to the necessary branches.
> I'm amused that you think there's anything in Debian's LDAP
> directory *besides the user accounts themselves that you're
> proposing to give people access to* that would warrant this level
> of granular access control.

I'm equally amused that you think there isn't.

tomfa@gluck:~$ ldapsearch -x objectclass=* | grep dn: | cut -d ' '
- -f 2- | sort | uniq -t = -W 1
cn=LDAP Administrator,ou=users,dc=debian,dc=org

Thijs suggested to allow the DAM to create the account directly
instead of just passing the stick on to yet another person causing
yet more delays. You were implying that it can't be done without
root access which I interpreted as giving write access to the whole
database. My assertion was that it can be done by giving DAM write
access to a specific branch in the tree, in this case the
"ou=users,dc=debian,dc=org" branch.

If it can be done and you just refuse do do it that way then say so
instead of expressing amusement based on unfair generalisations.

And if you feel uncomfortable to give DAM write access to
ou=users,dc=debian,dc=org directly, then let DAM create new accounts
in a sandbox node from where entries can be moved to the right
place by a cron script that can be programmed to make sure no
existing accounts is tampered with.

- --
Tomas Fasth <tomfa@debian.org>
GnuPG Fingerprint: DC7B 9453 7F26 1BF9 6B21 9F90 C187 7355 9FE8 D504
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Reply to: