Subject: Re: union mount directory permissions
To: Eric Haszlakiewicz <erh@jodi.nimenees.com>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-kern
Date: 09/27/2004 22:17:37
On Mon, Sep 27, 2004 at 07:21:52PM -0500, Eric Haszlakiewicz wrote:
> 
> 	I recently setup up some union mounts to easily play around with 
> building pkgsrc for multiple different OS versions.  That worked fine
> until I tried to build as non-root.  I noticed shadow directory
> ownership and permissions don't get set right.  Then I found this
> in union_subr.c:
> 
>      * policy: when creating the shadow directory in the
>      * upper layer, create it owned by the user who did
>      * the mount, group from parent directory, and mode
>      * 777 modified by umask (ie mostly identical to the
>      * mkdir syscall).  (jsp, kb)
> 
> uhm.. so, why?  File permissions and ownership are copied.  Shouldn't
> directories behave the same?

I think the intent of the policy decision is pretty clear (though if you
want to ask Pendry, I'd be curious to know what he had to say about it):
one major use of union mounts is to let users modify "read-only" directory
trees.  If /usr/src were owner root, mode 700, and I union mounted
/home/tls/mysrc on top, if the shadow directory permissions followed the
bottom layer's permissions, I'd have a useless union mount: I could not
create any files even in my top layer!

Of course, another point of view says that this does not belong in the
union layer; if you want such behaviour, stack a umapfs *on top of* the
unionfs.  I suspect that at the time, there was a strong inclination to
cram extra "useful" functionality into common layers like unionfs because
the deeper the stack, the less likely things were to work... which may
very well still be true.

There's another interesting question about removing this behaviour from
unionfs and using a triple-stack with umapfs instead: with umap at the
very top, the actual on-disk copy of the top-layer files will actually
end up owned by root, in my example -- so if you let users make files
setuid, for instance, you've created a security hole if there is any
path by which they can access the intermediate layer.  But I think there
are some problems with stacking the umapfs between the bottom and top
layers, too -- now, file ownership in the bottom layer looks wrong...
hm, but I guess it does with the top stacking, too.  Neither way gives
you _quite_ the policy that is built into unionfs now.

I bet it wouldn't be hard to write a layer that did, though.  And we
could always use more stacking filesystem experts. ;-)

Thor