execution from unionfs issue

[Bruce Evans]

On Mon, 5 Jun 2006, Scott Long wrote:

> Bastiaan Welmers wrote:
>> When mounting a tree on a directory as lower layer and I execute a
>> binary from the lower layer, it will create a non-executable copy of the
>> binary file on the upper layer:
>>
>> It look likes when executing files it will try to open it read-write or
>> something (for updating access time?) and unionfs creates a new
>> (non-executable) copy on the upper layer. I don't know this is desirable 
>> behavior or not in general, to me it
>> isn't at least. (I use it to provide basic userland for jails) I found
>> the "noatime" mount option helps to resolve the problem, but I can't find
>> this in any documentation.

> The copy is created in the upper so that the access time can be updated.
> This is intentional.  The permission that the upper copy is created with
> is obviously wrong though.  I would have thought that the copy node
> would have the same attributes and access properties of original node.
> Do try the new-and-improved unionfs patches that the sibling post
> refered to.  If it still doesn't work, then I imagine that GOTO-san
> would be happy to help fix it.

It's a bug for updating an access time on exec or read to create a
copy of the file.  Probably the file is read-only and, due to a bug,
unionfs thinks that it needs a update to update the access time on
exec.  It would be obviously wrong to make a copy on read, but equally
obviously wrong to not update the access time on read iff lower layers
would do that.  Exec doesn't require write access for updating the
access time any more than read does (it just requires exec access
corresponding to read requiring read access).  Unionfs should pass all
requests to update access to lower layers.  Setting of access times
on exec is supposed not to happen unless all levels of the file system
support it (since for some file systems it would be a large pessimization,
and some levels might just not support it).

Bruce