Re: Adding entries to a directory

[Sergiu Ivanov]

Hello,

On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
> On Tue, Nov 17, 2009 at 11:57:46AM +0200, Sergiu Ivanov wrote:
> > On Mon, Nov 09, 2009 at 02:58:12PM +0100, Carl Fredrik Hammar wrote:
> > > On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafBuddenhagen@gmx.net wrote:
> > > > 
> > > > > Well, obviously, O_READ permission on a directory is sufficient to
> > > > > create files in it.
> 
> > > How to properly verify whether a client has this access in
> > > a proxy such as unionfs is an interesting question.
> > > If run by root it could recreate whatever auth object
> > > the client is using, but its harder for a normal user.
> > 
> > Generally, unionfs checks permissions whenever it is asked to carry
> > out some operation.  Similarly, when it is asked to create a new entry
> > under a directory, it first checks the user's permissions.
> 
> Ah, yes.  That's what I thought.  Perhaps I should've explained what I
> meant by ``properly'', which I left out in this little side note.
> 
> The problem with relying on file permissions is that it is only one
> of several possible ways to specify permissions.  For instance, ACLs
> (Access Control List) can offer a more fine grained control, where
> permissions can be specified for individual users.
> 
> Now only regular file permissions are currently implemented by filesystems
> in the Hurd, but it would be nice to have the possibility to implement
> such alternatives in the future.  To ensure this we shouldn't rely on
> file permissions being correct.

I see.  However, if I understand you correctly, you are talking about
a totally different implementation of filesystem authentication
mechanism.  In case such mechanism is ever implemented, I believe that
the permissions check in unionfs can be pretty easily adapted to the
new way: unionfs relies heavily on libfshelp, and the corresponding
permission check functions could be modified to work differently.
 
> (But I might be missing something, perhaps POSIX says that regular file
> permissions should always be correct or something.)

Hm, why could POSIX say that regular file permissions may *not* be
correct? :-) I may be missing something, but it's hard for me to
imagine that POSIX file permissions were introduced with the thought
in mind that they may be wrong.
 
> > Although I fail to realize how unionfs would help root to recreate any
> > auth object used by a client, I'd believe that root could recreate any
> > auth object without the aid of unionfs, too :-)
> 
> My idea was that a unionfs *run* by root can recreate any auth object
> that the client has and then authenticate with it against the unioned
> directories.
> 
> If run by any other user then it can only recreate the intersection of
> credentials between unionfs and the client.  This isn't ideal, but it
> does ensure that unionfs doesn't accidentally grant the client any new
> permissions by mistake.

>From the theoretical point of view, there isn't really a problem,
since unionfs should always grant permissions which are intersection
between its permissions and the permissions of the calling client.
Even if unionfs is running as root, it shouldn't give the calling
client more permissions than they already have.  OTOH, bugs can bring
about security problems in any case :-)
 
> But just to clarify, I don't really propose that you implement this in
> unionfs.  I think this would affect other filesystems as well; switching
> over the Hurd to such a policy should be treated as a separate project.

Yeah, this is clear :-) Indeed, modifying the security policy will
involve a lot of modifications to all Hurd components.

Regards,
scolobb