Re: mount_checkdirs
> My inclination is that it is wrong [...] It looks strange to me, but that doesn't tell much. Could it have been added as a quick fix for the behaviour of some (then) standard daemon or the like? > The logic was added to 4.4 by Kirk McKusick but without much in the > way of rationale: Perhaps the easiest thing would be someone asking Kirk Himself whether he can remember?
Re: mount_checkdirs
On Jul 9, 12:27am, Rhialto wrote: } On Mon 06 Jul 2015 at 09:58:59 +, David Holland wrote: } } > Also it's occasionally useful to mount over things and leave a process } > underneath, which this logic seems to complicate. } } If I read the code correctly, it looks for processes that have a current } working directory or root directory exactly at the mount point. But the } mount point directory does not need to be empty. A process could have a } cwd or root in any directory inside it. So as-is, the code is } insufficient for its intended purpose anyway. } } Furthermore, the process can have open files from that directory tree. } If its cwd or root gets changed (and into what exactly, if it isn't the } exact mount point?) it has files open that it can't find anymore with } another call to open(2). That seems like an inconsistency that we may } want to avoid due to the POLA. The same process or another process could unlink the open file. There is no guarantee of being to open(2) a file twice. }-- End of excerpt from Rhialto
Re: mount_checkdirs
On Thu 09 Jul 2015 at 00:27:18 +0200, Rhialto wrote: > That seems like an inconsistency that we may > want to avoid due to the POLA. I may even see an escape from a chroot : 1. process gets chrooted to /altroot 2. it cds into, say, tmp 3. outside, somebody mounts a new system on top of /alroot 4. the process' root gets fixed, but not its cwd 5. cwd is now not inside its root, so successive "cd .." escapes to the real root. I gave it a quick try with "pkg_comp chroot", the shell it starts, and mounting an install usb stick on top and it didn't work immediately. What I saw in practice with an "ls" after point 4 was "ls: fts_read: operation not permitted" so there is some detail that prevents the exact scenario that I tried. But it doesn't seem to be in mount_checkdirs(). It could be something /bin/sh does. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpo3b_YAd2x0.pgp Description: PGP signature
Re: mount_checkdirs
On Mon 06 Jul 2015 at 09:58:59 +, David Holland wrote: > Also it's occasionally useful to mount over things and leave a process > underneath, which this logic seems to complicate. If I read the code correctly, it looks for processes that have a current working directory or root directory exactly at the mount point. But the mount point directory does not need to be empty. A process could have a cwd or root in any directory inside it. So as-is, the code is insufficient for its intended purpose anyway. Furthermore, the process can have open files from that directory tree. If its cwd or root gets changed (and into what exactly, if it isn't the exact mount point?) it has files open that it can't find anymore with another call to open(2). That seems like an inconsistency that we may want to avoid due to the POLA. It seems inconsistent to me to "fix" processes that are exactly at the mountpoint directory, but not ones more inside. A possible reason not to handle subdirectories could have been that semantics for that are unclear. But one would have expected some note about that somewhere, given the above. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpfjaLYXUsBs.pgp Description: PGP signature
Re: mount_checkdirs
Date: Mon, 6 Jul 2015 09:58:59 + From: David Holland My inclination is that it is wrong, and if we care about not starting lookups in the middle of mount stacks that the logic should moved to namei; and if we don't, it should just be removed. Thoughts? Doing it in namei sounds reasonable to me. But first we should try to cook up some test cases that distinguish the different behaviour, or sketch a proof that we can't. Some tests to exercise possible races in mount/fork/*at over the cwd might be worth writing.
