Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

[Michael Orlitzky <mjo@gentoo.org>]

On 01/19/2018 07:16 PM, William Hubbs wrote:
> 
> It looks like we can't use your --as suggestion if we want to be
> able to create paths in /var/lib and /var/spool that are owned by
> non-privileged users because of the permissions on those paths. It is
> possible that service scripts are doing this.
> 

Why not? Since /var/lib is root:root and mode 755, we can create
/var/lib/foo while running --as=root (the default). Then afterwards,
anything beneath /var/lib/foo would need to be created "--as" the owner
of that directory.

/var/lib or /var/spool should be no different than /run in that regard.

(Although, the ebuild should be responsible for /var/lib and /var/spool)


> Is it worth changing the algorithm to do this instead:
> 
> 0. test for existance by opening a read-only file descriptor to this
> file.
> 1. Creating the file/directory/fifo.
> a. If it doesn't exist, create it -- note that I'm not setting
> permissions with the create call.
> b. Open a read-only file descriptor that attaches to the newly created
> file.
> 2. Setting Permissions.
> a. Fix the permissions of the file if necessary.
> 3. setting ownership
> a. Set the ownership if it doesn't match the specified ownership.

Is this for checkpath? Steps (a) and (b) would need to happen at the
same time. Is there a way to determine if a file descriptor is for a
hard link? There are likely some small ways that we could still improve
checkpath, but the main issue I'm trying to solve by jumping through all
these hoops is the hard link race condition.


>> Risk #2: Instead consider a four-component path /run/foo/bar/baz. If you
>> start creating those directories with owner "foo", then when you get to
>> creating "baz", it's possible that "bar" has been replaced by a symlink
>> somewhere else.
>  
>  It is possible, sure, but the question I would ask is, could this also
>  be a legit situation where a user would want /run/foo/bar to be a
>  symlink to some other location? If it is, there's no way to tell the
>  difference.

The init script author can use the real path instead of the one
involving the symlink if he needs to. So maybe he wants /run/foo/bar to
be a symlink to /herp/derp, but then instead of doing

  newpath /run/foo/bar/baz

he could do

  newpath /herp/derp/baz

and then there are no symlinks involved.