On Mon, Apr 07, 2003 at 12:53:53AM +0200, Ivan Popov wrote:
> I am thinking about the semantics of some meta-information that Coda
> maintains.
> 
> Neither file owner nor access bits are used for the decisions about
> granting access to a file.

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.

> This information is used (and wrongly relied upon) by some programs
> assuming Unix semantics.

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.

> With other words, trying to map server-side Coda uids to client-side
> local OS uids is just a hack that can work on smaller installations but is
> deemed to problems and "impossibilities" in the long run.
> 
> Nowadays Coda becomes a global filesystem, allowing access to multiple
> realms. The same client can talk to different realms with totally
> independent Coda uid assignments. It can be a better illustration for the
> 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. I could give mail delivery as a perfect example, except that we
don't have PAG support anywhere. But the idea of mail delivery when we
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).

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
authenticated as the delivery agent and as such doesn't require user
tokens. With a maildir type inbox, the ACL can then very effectively
control access and disallow many forms of abuse.

    cfs sa Mail/tmp maildelivery wlid 
    cfs sa Mail/new maildelivery li 
    cfs sa Mail/cur maildelivery none 

Using these ACLs a compromised mail delivery agent can only add new mail
or possibly overwrite mail that is in the process of being delivered,
but has no way to read or remove already delivered messages. But here we
do have the situation that many local userid's are using a single Coda
identity.

In the same way, a local user-id can have several Coda identities. I
have a local userid of 500, but Coda uid 7768 within coda.cs.cmu.edu,
and something like 1000 in the testserver.coda.cs.cmu.edu realm.

> What is the best approach / approximation?

Right now the only working approach that I've found is to return pretty
much whatever chown/chmod has set in the next stat(2) call. Anything
else is fair game. I believe I do this right now by not invalidating the
cache attribute data in the kernel after a chfoo operation, so a newly
created file will typically show up with the local uid. Once the kernel
cache expires for some reason venus is consulted and the user id becomes
that of the Coda id (although that might even require a fetching from
the server).

> [*] as we show file owner id being the same as the uid of the process
>     doing stat() and as we can set access bits according to the
>     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
kernel's attribute cache and force a new upcall when a different local
user tries to get the attributes of an object.

On the other hand, I like the ideas a lot. Maybe I'll just try it some
time and see what the penalty really is.

> For the purposes of [2] we might provide something like "cfs ls-l" that
> would generate ls-like output but translate uids to account names
> internally, not via the client side naming service - that will be the
> "right" creator information, also including the realm:

cfs has a really bad interface for arbitrary length data because we have
a limited buffer that is passed through the kernel to venus and back. In
some places this is worked around by using a temporary file and passing
the name, which isn't the most reliable solution either.

Jan