Coda File System

Re: acl "transitivity"

From: <>
Date: Tue, 26 Jan 2010 12:32:21 +0100
Hi Don,

On Tue, Jan 26, 2010 at 02:32:55AM -0800, root wrote:
> >On the other side, you should not assume that protecting a volume root
> >directory protects all data in that volume. There may be ways to access
> >other objects in the volume given some extra information and given a
> >suitable ACL on _that_ object['s directory]. So better do not assume
> >transitivity of the ACLs even inside a single volume. If curious see a
> >recent discussion on openafs-devel list.
> I'm confused.  By this, it almost appears that there is no file access 
> security within coda.  I.E.:  If a user can login to a given coda.realm, a 
> sufficiently motivated individual with said user access could gain 
> unauthorized access to any file available within that realm. 

Did you read my statement carefully?

> However, I think what must have been meant is that as long as ACLs are set 
> on all directories to provide access only to a given user, those files 
> should be secure from a different user on a different client host.  That 
> seems like a godawful amount of setup and maintanence for rudimentary file 
> access permissions, however.  I still don't think I've got it right. 

Hmm. Security without setup and maintenance may be desired but hardly
exists. For rudimentary permissions needs you need rudimentary setup,
for advanced needs you need an advanced setup. Coda offers reasonable
tools for both.

> Given the following environment, what is the minimum ACL/chmod/chown 
> necessary to provide sandboxed access: 

Forget chmod/chown.

> coda_user_1 only can logon to client_host_1 which has exclusive listing,
> read, and write access to coda_volume_1

Forget "client_host". It is irrelevant for access-rights-related discussion.
Forget "logon". It has nothing to do with Coda security [model].
Forget "volume" when you are talking permissions, think "directory".

It seems that your thought setup is not being designed with Coda
security model in mind. My best suggestions for going further are
listed above.

Received on 2010-01-26 06:34:15