Re: Thinking outside the box on file systems

[Marc Perkel <mperkel@yahoo.com>]

--- Kyle Moffett <mrmacman_g4@mac.com> wrote:

> Al Viro added to the CC, since he's one of the
> experts on this stuff  
> and will probably whack me with a LART for
> explaining it all wrong,  
> or something. :-D
> 

Thanks - I appreciate that.

Just to catch everyone up on what this thread is
about, I'm proposing a new way of looking at file
systems where files no longer have permission, owners,
or groups, or file attributes. The idea is that
people, groups, managers, applications, and other
objects have permissions to names that are pointers to
files.

> On Aug 15, 2007, at 16:38:36, Phillip Susi wrote:
> > Kyle Moffett wrote:
> >> We've *always* had to do this; that's what "chmod
> -R" or "setfacl - 
> >> R" are for :-D.  The major problem is that the
> locking and lookup  
> >> overhead gets really significant if you have to
> look at the entire  
> >> directory tree in order to determine the
> permissions for one  
> >> single object.  I definitely agree that we need
> better GUIs for  
> >> managing file permissions, but I don't see how
> you could modify  
> >> the kernel in this case to do what you want.
> >
> > I am well aware of that, I'm simply saying that
> sucks.  Doing a  
> > recursive chmod or setfacl on a large directory
> tree is slow as all  
> > hell.
> 
> Doing it in the kernel won't make it any faster.
> 
> 
> > As for hard links, your access would depend on
> which name you use  
> > to access the file.  The file itself may still
> have an acl that  
> > grants or denies access to people no matter what
> name they use, but  
> > if it allows inheritance, then which name you
> access it by will  
> > modify the effective acl that it gets.
> 
> You can't safely preserve POSIX semantics that way. 
> For example,  
> even without *ANY* ability to read /etc/shadow, I
> can easily "ln /etc/ 
> shadow /tmp/shadow", assuming they are on the same
> filesystem.  If  
> the /etc/shadow permissions depend on inherited ACLs
> to enforce  
> access then that one little command just made your
> shadow file world- 
> readable/writeable.  Oops.
> 
> Think about it this way:
> Permissions depend on *what* something is, not
> *where* it is.  Under  
> Linux you can leave the digital equivalent of a
> $10,000 piece of  
> jewelry lying around in /var/www and not have to
> worry about it being  
> compromised as long as you set your permissions
> properly (not that I  
> recommend it).  Moving the piece of jewelry around
> your house does  
> not change what it *is* (and by extension does not
> change the  
> protection required on it), any more than "ln
> /etc/shadow /tmp/ 
> shadow" (or "mv") changes what *it* is.  If your
> /house is really  
> extraordinarily secure then you could leave the
> jewelry lying around  
> as /house/gems.bin with permissions 0777, but if
> somebody had a back- 
> door to /house (an open fd, a careless typo, etc)
> then you'd have the  
> same issues.

My proposal is the same somewhat. If one put
restricting on a specific name to deny access to users
then that denial follows that filename even if it is
copied or moved. However if a file has no specific
restrictions and is in a restricted directory then the
file inherits the restrictions and permissions of the
new directory based on where it is.

If you don't want your jewlery laying around then
don't put a copy of it in a folder where users have
access to it.




Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com


       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC