Coda File System

Re: a step backwards

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 27 Aug 2004 18:02:01 -0400
On Fri, Aug 27, 2004 at 10:40:23PM +0200, Ivan Popov wrote:
> > Bigby Findrake <bigby_at_ephemeron.org> writes:
> > > Has anyone stripped down coda to make it work without client
> > > authentication?
> 
> You do not need to strip down authentication,
> just use it in the way which you find suitable.
> 
> Setting ACLs allowing anonymous read and write will open your data
> to the world, if it really is what you want :)
> 
> "cfs sa /coda/your.realm System:AnyUser rlidwka"
> 
> and the same at mountpoints before creating directories in new volumes.
> 
> It may work fine, if you have a totally isolated network.
> Otherwise you _do_ want authentication and protection.

No, that really only works if you never write anything. The CML is owned
by a single user (design decision), and reintegration only happens when
that user authenticates. Since any write-write conflict (or network
hiccup) will kick the client into (write-)disconnected mode this is
pretty much unavoidable.

So yes, authentication is pretty much hardwired in a lot of places.

As far as cron triggered reauthentication is concerned, if you can trust
the local root user, simply create a directory that only root can
access which contains files with passwords. Then run

    mkdir /etc/codaauth
    chmod 700 /etc/codaauth
    echo "foobar" > /etc/codaauth/someuser
    chmod 400 /etc/codaauth/someuser

crontab:
    clog -as someuser < /etc/codaauth/someuser

Since the crontab runs as root it can open the file, but as soon as clog
starts it uses setuid to change to the uid of someuser who normally
can't access any of those files, but we already have the open fd.

I guess the user could still attach gdb and get access to his own
password, but at least he can't see any of the others.

Jan
Received on 2004-08-27 18:03:26