From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <6e35c0620601242346q256802f1j48b1f1cd547fbf0f@mail.gmail.com>
References: <43D53D9F.90702@lanl.gov>
	<20276.1138167055@piper.nectar.cs.cmu.edu>
	<6e35c0620601242346q256802f1j48b1f1cd547fbf0f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <16DE3DE0-B4FD-4266-822A-0ABDBBD3DE03@orthanc.ca>
Content-Transfer-Encoding: 7bit
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Subject: Re: [9fans] fuse bashing
Date: Wed, 25 Jan 2006 00:11:18 -0800
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Topicbox-Message-UUID: e72e8d4c-ead0-11e9-9d60-3106f5b1d025


On Jan 24, 2006, at 11:46 PM, Jack Johnson wrote:

> Not ACLs, but I've thought it would be nice to reuse SSH keys and
> maybe make another dot-directory, and anyone with a matching public
> key in the dot-directory would have access to it, similar to
> .ssh/authorized_keys but with a separate file per user.

But these *are* ACLs, and by putting them into the filesystem you're  
trying to protect you create an intractable recursive problem: how to  
protect the ACLs with themselves.

To secure the filesystem you have to isolate this metadata. The  
problem to date is that nobody has figured out a clean way of doing  
this in a way that makes it simple to administer -- and maintain --  
the ACLs (and other crud).  E.g. FreeBSD supports ACLs in the  
filesystem, but all the tools that manipulate files need to be  
cognizant of them, and sadly, most aren't.  Thus an application that  
does it's work on a temporary file and then does the 'unlink(foo);  
rename(tmp,foo)' dance loses the ACL attributes (and other  
metadata).  On occasion I wonder if this asks for a replace(a,b)  
syscall that does the equivalent atomic unlink+rename while  
preserving the metadata (ACLs, MAC labels, etc) associated with the  
original file.

--lyndon