On Wed, 11 Aug 2004, Ivan Popov wrote:

> Hello Jan,
>
> > does coda deny access to the root on the client that does not have
> > any account on coda server, but changes identity (su user) to the user
> > that has such an account, in order he can manipulate the user's data?
>
> root can access all local objects independent of who is the owner.
> It includes cached Coda files, memory image of a Venus process or
> the clog command.
>
> There is no protection form root whatsoever on a computer where you clog
> and access /coda (root can steal your password, to begin with, and the
> tokens as soon as you have got them).
>
> On the other side, a server is totally agnostic of the uids on a client,
> it evaluates tokens that a client process presents. In that way,
> noone (root or not) on a host where I do not clog could steal my files,
> as noone can posess/produce tokens valid for pretending to be me.
>
> Hope it answers your question.
>
> Regards,
> --
> Ivan

Thank you Ivan, it definitely answers my qustion.
I got another if u don't mind.

So if I got it well, after the user clog to the server the tokens he/she
acquired from the auth server are propagated to venus.
So that's why root (or any one else who knows users's password) can su to
user and thus get the rights to access users distributed files, right?

If the tokens were not stored on the disk but kept in memory (in user's
task struct) the simple switch to user wouldn't help anyone, right?
Only root could access it via a kernel hack.

Is there any way to force venus not to cache any thing?
Also I guess AFS works almost the same way, doesn't it?

Thanks for your time.

I'm just asking such "strange" question, cos I need to do
some process migration mechanism and use some secure distributed fs

Jan