Coda File System

Re: Coda for home directories and NIS vs. Kerberos

From: <u+codalist-p4pg_at_chalmers.se>
Date: Fri, 1 Feb 2008 09:35:41 +0100
On Thu, Jan 31, 2008 at 08:52:08PM +0000, coda_at_bobich.net wrote:
> docelic wrote:
> >project). It's a NSS module similar to libnss-ldap, but it retrieves
> >user info from AFS ptdb instead of from LDAP.
> >
> >http://instantafs.cbs.mpg.de/ , even though it seems to be down ATM.
> 
> I don't speak German, so that site is quite incomprehensible. :-(
> 
> >That could be adjusted to read from Coda's user db instead. Extra
> >benefit is that you don't have to sync passwd files around, and 
> >names in 'ls' match the real usernames.
> 
> Sounds ideal! :-)

Be careful, all the benefits you expect from such a solution
postulate a "shared" system administrator between the realm
and the client computer. It is not going to work, as soon as either
- more than your own realm is accessed from your client computers
- more than your own computers are used to access your realm

You would mostly multiply the users' confusion as sometimes it would seem
to work, but sometimes ls output will look just crazy :)

Coda is not a suitable place to try to simulate Posix.

> I was actually just thinking about something this ever since Rune 
> mentioned building the system around Coda, rather than the other way 
> around. Authenticate logins against Coda's user database. All I have to 

Caution again, Coda authientication is designed to authenticate
against _Coda_servers_, not as Kerberos to be a trustable third party
for other services. A straightforward (na´ve) use of pam_coda for
login authentication does not provide any security even if it "seems to work".

> do now is figure out how to adapt this nss module to work with coda. 

Sigh. Let me speak out, hopefully last time in this discussion:

---- Do not spend your time trying to get Coda and NSS together.
     You would just waste yout time and make your (and others)
     suffering and confusion longer and more painful.

NSS is a directory service, doing mapping between numerical uids
and account names, likewise for groups.
This is totally irrelevant for Coda. In fact, some future version of Coda
might totally drop using integers as internal identifiers and use e.g. strings.
It is a matter of implementation, not of semantics.
The numeric uids were chosen at the time no one thought about globality,
multiple realms' concept was hardly practical. At those times imitation
of unix uids seemed to may have sense even for AFS/Coda.
It was also seasoned system administrators who created AFS and Coda
and they also needed time to unlearn some "truths".
So much for the numerical uids themselves.

The other function of the NSS is to map uids to group memberships.
This is designed and used for implementation of the Unix/Posix privilege
model, which is in fact a very limited special case of ACLs
(an acl per file containing exactly three entries,
the first one containing a reference to an account, the second one to a group,
the third one - to a special group including all users of the computer).
This model can not be mapped one-to-one to/from Coda groups,
as one privilege model is a subset on the other.

In other words: forget nss with Coda, they belong to different worlds
and even if forced to marry could hardly leave any offspring...

> Something tells me that it won't "just work" as it is...

:)

Best regards,
Rune
Received on 2008-02-01 03:38:08