bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] Implement mountee startup.


From: Carl Fredrik Hammar
Subject: Re: [PATCH 2/3] Implement mountee startup.
Date: Mon, 9 Nov 2009 14:58:12 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

On Thu, Nov 05, 2009 at 12:29:54PM +0100, olafBuddenhagen@gmx.net wrote:
> 
> > > > > Why are you passing O_READ, anyways?...
> > > > 
> > > > The flags which I pass to start_mountee are used in opening the
> > > > port to the root node of the mountee.  (I'm sure you've noticed
> > > > this; I'm just re-stating it to avoid ambiguities).  Inside
> > > > unionfs, this port is used for lookups *only*, so O_READ should be
> > > > sufficient for any internal unionfs needs.  Ports to files
> > > > themselves are not proxied by unionfs (as the comment reads), so
> > > > the flags passed here don't influence that case.
> > > 
> > > Hm, but wouldn't unionfs still need write permissions to the
> > > directories for adding new entries, when not in readonly mode?...
> > 
> > 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.

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.

Regards,
  Fredrik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]