Re: Adding entries to a directory

[Carl Fredrik Hammar]

Hi,

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.
> > > 
> > > Ah, interesting...
> > > 
> > > > I'm not sure whether this is a feature or a misbehaviour
> > > 
> > > I don't think it's a bug -- doesn't seem very likely that nobody would
> > > have noticed such a fundamental bug all this time...
> > 
> > I was about to say it's definitaly a bug, but a quick look in open(2)
> > states that open() should fail with EISDIR if open mode is write...
> > This suggests that adding entries depend on the permission bits
> > of the directory and the users and grougs of the client.
> 
> Thank you for the investigation! :-) It didn't occur to me to look
> into manpages first :-(

No biggie, it was buried deep inside the man-page.  It was pure chance
that I noticed it at all.

> > 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.

(But I might be missing something, perhaps POSIX says that regular file
permissions should always be correct or something.)

> 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.

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.

Regards,
  Fredrik