Re: Unionfs, looking up links and translators

[Thomas Bushnell, BSG]

Moritz Schulte <moritz@duesseldorf.ccc.de> writes:

>   I was thinking about what unionfs should do with symbolic links and
> translators on the underlying filesystems; i think if unionfs's
> _S_dir_lookup would return retry names in that case, that would be
> reasonable.

Yes, that's right.  It needs to do it with O_NOTRANS.

>   It would create some problems if unionfs would simply use
> file_name_lookup (without O_NOTRANS/O_NOLINK/O_NOFOLLOW) to search for
> files on the underlying filesystems: if a link points back into the
> (absolute path of the) unionfs, this would create a dir_lookup-loop,
> since unionfs has no way to distinguish between a dir_lookup call from
> the user and a dir_lookup call from the unionfs itself.  The same
> problem - in a more general way - is present with nodes, on which a
> translator is installed; unionfs cannot predict it.

Yes, quite right.  It needs to do it with O_NOTRANS.

>   But there is one basic problem: the node can be modified after
> unionfs' dir_lookup returned the retry port/name but before glibc
> continued resolving the path name.

unionfs should probably not be looking anything up, I think.  

>   One example for the problem: If the node, for which a retry
> port/retry name was returned by unionfs' dir_lookup, is deleted before
> glibc looked it up itself, ENOENT will be returned.  This means:
> although there might be other files with the same name in the unionfs,
> the user _could_ receive ENOENT.

Then you're doing the wrong retry.

Look up the node with O_NOTRANS, and then return *that* to the user,
with FS_RETRY_REAUTH and a retry name of ".".  You have to do this
*anyway* in order to get the right permissions set on the node.

You don't tell the user what directory and name to look up; that has
races (as you note)!  Instead, you fetch the actual node, and then
tell the user to reauth *that* node.  This has no races.