On Mon, Apr 07, 2003 at 11:37:01PM +0200, Ivan Popov wrote:
> > To some extend, as we have made some compromises. The owner bits are
> > being used to some extent to 'refine' the ACL permissions. So a file
> > with only the read bit set is not writable even when the ACL permits
> > writes.
> 
> Hmm, it reminds me of dfs "mask object" and I can tell you from
> experience, it is a dangerous way, creates lots of confusion.
> We have been there with dfs.
>
> (I assume that the uid check, if any, uses Coda uids, otherwise it would
> be semantically just plain wrong?)

Probably similar or identical, this stuff is most likely inherited from
AFS2. Ofcourse your assumption is wrong and this stuff is semantically
broken. What did you expect ;)

> > have process authentication groups would be that the mail delivery
> > process would do it's normal setuid stuff before it delivers an email to
> > the user's inbox, but keeps the 'PAG' (i.e. Coda token).
> 
> You wouldn't need PAG, just let mail agent run as a local uid without
> local rights, no setuid(<user>) required.
> In fact, the is no need for local uids at all.
>
> Remember, if your mail server accepts mail over smtp and deliveres it to
> Coda, it has nothing to do with the computer's OS, uids in its /etc/passwd
> or similar. All you have to know, which *names* shall accept mail and
> where on Coda the corresponding mailboxes are located, that's all.
> 
> (you see, the ancient ideas about users sitting on the same host as the
> smtp daemon runs are not easy to get rid of :)

You are ofcourse right. The mail delivery process wouldn't even have to
run root once it has bound to the appropriate low port. It is very hard
to step away from the worn-down pathways in my mind that tell me how it
currently works and how to smash that concept into Coda, instead of
thinking about how it should work.

Jan