Coda File System

Re: Coda credentials for uid 0

From: Ivan Popov <pin_at_math.chalmers.se>
Date: Tue, 24 Sep 2002 19:41:58 +0200 (MET DST)
On Tue, 24 Sep 2002, Jan Harkes wrote:

> > On Tue, 24 Sep 2002, Ivan Popov wrote:

> > After consideration I want to withdraw this idea as it implies a need for
> > complementary unix-like uid-based access control.

> > My conclusion: PAGs are of no real use!

> operations. Example maildelivery, I could set the ACLs on my maildir
> directories as follows to allow mail to be delivered by 'root' with pag
> 'mail'

Exactly what I meant - it implies more complicated acl management, both
implementation-wise and harder to understand for the users.
You would have to grant the rights based on both process uid ("root") and
credentials ("mail"). Or rather process uid ("me") and credentials
("mail"), because setuid() forgets about having been root...
Or what did you mean by "delivered by 'root'"?

If we check against "root before setuid()" and "mail-credentials", we
still have a problem in case of procmail - granting a user process power
over other users mail dirs.

I strongly suggest not going that way.

> I wouldn't need to have a cronjob on the server that tries to maintain
> tokens for all users.

No, you may have misunderstood. I was talking about cron jobs just because
it is a common confusion source for our users with homedirs on dfs. Their
cron jobs cannot access their files, and that is right :)

It is one of the reasons dfs homedirs are no longer created for new
accounts! :-/
While a simple policy decision about using a local dir for the cron things
did never made through. Shame.

These dangers are lurking in the shadows for Coda, too!
That's why
 - good recipes are important
 - understandabity is *very* important

Codas acls are a lot easier than dfs ones, and I'm convinced it pays for
the missing features. More complicated logic to cover special cases (dfs
approach!) is hardly recommendable.

Regards,
--
Ivan
Received on 2002-09-24 13:44:10