On Thu, Feb 21, 2002 at 01:25:41PM +0100, Ivan Popov wrote:
> On Mon, 18 Feb 2002, Jan Harkes wrote:
> 
> > The only way we could block non-root users from seeing the cache is by
> > encrypting the tokenfile with the user's password and some additional
> > randomness provided by venus. Then if we pass up the token and the
> > password, venus can decide if it is a unchanged token and whether it
> > trusts the userid. The servers can still be used to check the validity.
> 
> Hello Jan,
> 
> I feel there might be a problem - venus does not see a user password with
> kerbers authentication.

But kerberos definitely doesn't work while disconnected. The idea is
that it should be possible to obtain a token while connected, either
using regular clog with password, or kclog with kerberos authentication,
and then securely store this token locally so that it can survive venus
restarts.

So either the user stores it in the local filesystem, or venus put's it
in RVM. In both cases this token should (optionally?) be secured with a
password, so that a random user (who does have an account on the
machine) cannot just log in and say 'hey I'm really Ivan, give me access
to my files'.

> Wouldn't it be possible in disconnected mode to just check against the
> uid of the process, while ignoring the groups or better mapping coda
> groups to the local ones as long as there are suitable ones? Well, say
> as an per-client option?

Coda clients don't know anything about groups. They get upcalls from the
kernel, which are tagged with 'credentials', these typically contain the
uid/euid/fsuid/process-id/session-id, we typically only use the fsuid
(euid on BSD systems) except in some weird cases such as the ASR and
hoard code.

But this 'credential' still doesn't give us any knowledge about who this
person/process is. So clog is used to obtain an identity in the form of
a token from the servers and passes this through the kernel interface so
that it get's tagged with the credentials and venus set's up the kernel
identity <> server identity mapping. The next time this user requests
something from the server, and the server accepts the token during the
connection setup the identity is considered valid. Then whenever an
object is accessed, it marked as 'accessible by this kernel identity'
(not Coda identity!).

When we become disconnected, the server can't declare token invalid, so
the accessible bits aren't being cleared until we reconnect and the
server sees the expired token.

When a client restarts there are no tokens, but the bits are still
there. As soon as a user passes up any blob of data that matches a
token, this user will regain access to any object that his 'kernel
identity' had access to before. Until ofcourse the servers see the
bad token, at which point it will be discarded and all the access bits
are cleared. (btw. cunlog will clear them as well).

> In many situations that would be sufficient (I want to work with my
> Coda files, and use public software from Coda), while more secure
> than the current situation you describe...
> 
> Otherwise it is in fact unacceptable to run Coda on multiuser machines,
> it is too easy to switch to disconnected mode and then access others'
> files...

This actually shouldn't be possible, but only because venus really
trusts 'kernel credentials' more than the 'token credentials'. But I
would have to double check to see which 'user-id' is put in the access
granted field of cached FS objects to be sure of this.

Jan