Hello,

> > Neither file owner nor access bits are used for the decisions about
> > granting access to a file.

Jan writes:

> 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?)

> And in fact most installers doublecheck whether the owner or mode bits
> are set correctly and fail if they don't match with the 'expected'
> values.

Hm, it is possibly not as bad? It is mostly security-related programs
which make (the wrong) checks. [sigh]

In fact, it is a great pain-in-some-body-parts
if you try to convince a legacy packaging system to use a global file
system. It is often not worth persuading.

Most of such packagers depend very heavily on the filesystem being local,
not (only) on modebits.

On the other side, it is always possible to transfer the files to Coda
from a local file system, if a stupid installer cannot cope with any
unusual setup. (typical problem - you have to be root, to proceed with the
install script :)

> > fact that synchronization between Coda uids and the client-side ones is
> > inherently impossible.
>
> Correct, in some cases several local user-id's might be using the same
> Coda id.

or the other way around, several Coda identities for the same uid,
at different times.

> I could give mail delivery as a perfect example, except that we

Oh, no, not mail delivery please! :) The ancient concept of using
filesystem as the protocol for delivering mail is so much misunderstood
and misused... but you seem to think rationally...

Ok, I buy the idea of using maildir on Coda instead of IMAP (gives
nice replication and failover - though needs Coda kernel support compared
to just TCP/IP support for IMAP), but I do not buy the following:

> 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 see, we might use filesystem for communication in the other
direction too, say for controlling mail filtering.
It could be files at certain places in Coda, containing a configuration
information, instead of ~/.procmailrc, but even then we'd *not*
need to have local uids for mailbox+configfiles owners.

> This way the delivery agent is 'safe' from local exploits as it runs
> with the local userid, but as far as Coda is concerned it is still

No, it is not that safe, as its tokens in this case give it the power
over all users' mailboxes at once.

> tokens. With a maildir type inbox, the ACL can then very effectively
> control access and disallow many forms of abuse.

Ok, I see, it gives a possibly acceptable compromise.

> do have the situation that many local userid's are using a single Coda
> identity.

I still think that mail delivery would not need multiple uids :)
but otherwise thanks for the illustration!

> >     actual process rights, stat() would work similar to access()
> >     and hence give the "right" result
>
> Nice, but breaks install/rpm/dpkg. We also have to invalidate the

I am really interested if
1. anybody is installing things with rpm / dpkg directly on Coda
   (presumably via some symlinks?) ?
2. puts even /etc-files on Coda ?
3. it works ?

[for the best of my knowledge, it shouldn't, on any filesystem,
neither rpm nor dpkg packages are built for distributed installations,
may be except for very special farms of exactly identical hosts
on a safe network]

> > translate uids to account names
> > internally, not via the client side naming service

> cfs has a really bad interface for arbitrary length data because we have

Pity. Then even a limited interface, omitting realm (it is usually evident
from the file path), say 8 bytes max name length - would be usable and
useful.

Regards,
--
Ivan