[OpenAFS] libnss-ptdb

Christopher D. Clausen cclausen@acm.org
Sun, 1 Apr 2007 13:10:54 -0500


Adam Megacz <megacz@cs.berkeley.edu> wrote:
> FB <fbo2@gmx.net> writes:
>>    * Some multithreaded applications (i don't remember exactly which
>>      ones) just didn't work with the thread model of Todd's module.
>>      AFAIK it had something to do with pthread v.s lwp but I'm not a
>> threading-expert.
>
> Ok, I'm going to look into this.
>
>>    * One of my cells contains a DB-Server which is off-by-default.
>>      Moving the PTDB-Code to a daemon prevents timeouts while
>>      marking DB-servers offline. This way I timeouts in any program
>>      accessing the uid-name-resolution are replace by a single
>>      timeout at daemon-start. -> A seriously wish, I had such a
>> daemon for host-lookups, too...
>
> I see.  I think nscd would achieve the same effect...
>
> Also, while I'm hacking on this, two more questions:
>
> 1. Does it make sense to map AFS group ids (with the sign reversed)
>    onto GIDs?

Probably, yes.  That way the local group can be used to protect 
resources, like cdrom or sound or whatever or you could use groups in 
sshd configs.

> 2. Previous suggestions about shells involved putting users into
>    groups named after shells, such as
>
>      pts add adam shell:bash
>
>    But it seems that this wouldn't allow users to manage their own
>    shells since shell:bash would belong to some administrative user.
>    What about an alternative, where users would create a group
>    "username:shell.bash"?
>
>      pts cg adam:shell.bash

You can set the PTS groups so that they allow anyone to add themselves:
http://www.openafs.org/pages/doc/AdminReference/auarf225.htm#HDRPTS_SETFIELDS

you want -access SOMAx
Not sure if that would allow them to change other users shells or not 
though, but thats easy to test for those so inclined.

You'd need a periodic cleanup process (run via cron on a trusted host) 
to remove the user from the old group when they are in two of them.  And 
it would probably be best to have a default shell (say bash) with no 
group and default users to this shell.  Most users I know only change 
shell once and it would be easy for them to add themselves to the 
shell:zsh group.

Or, have a web interface that actually runs with "shell" tokens to allow 
users to change their shells and don't mess with the PTS group 
permissions.

Bascially, even if it requires system administrator intervention to 
change shells, it would still be superior to running NIS or LDAP just 
for shell and home directory information.

In fact, it might be simpler to have a PTS DB extention that emulates an 
NIS server and run it on the AFS DB servers.  That way you wouldn't need 
to port the nss module to various OSes.  (I suspect it would be painful 
to port to AIX.)

<<CDC