On Fri, Jan 19, 2018 at 07:53:06PM -0500, Michael Orlitzky wrote: > 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.
That would create an extra level of indirection for some things though, what if /var/lib/foo needs to be owned by foo? I have /var/lib/dhcp which is owned by dhcp:dhcp. You can't creat that with --as=dhcp. > > /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. You mean steps 1 (a) and (b)? They would happen in the sequence shown. The only call that gives you a file descriptor is open() which is not used to create a directory or a fifo. The link status is available via fstat() or stat(). An example of checking it is in line 146 of checkpath.c. We refuse to chmod a file that has more than one hard link to it. > > > >> 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. Let me think about this... :-) William
signature.asc
Description: Digital signature
