(Headers on this one might be weird because the ssh session died, so I had to go through weirdness to recover the email...)
On Sat, Dec 21, 2013 at 07:59:37PM +0100, Armin K. wrote: > On 12/21/2013 07:16 PM, Bryan Kadzban wrote: > > On Sat, Dec 21, 2013 at 04:33:42PM +0100, Armin K. wrote: > >> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) > > > > Why add nosuid or noexec? > > > > I didn't add anything. It's what systemd does by default. Please note > that this might be not the only variant. O...K... another reason to never touch systemd with a ten foot pole. It's trying to restrict root when that's both unnecessary and (in this case apparently) harmful. Sigh. > >> I would certainly not want lfs to modify my host system. > > > > That's one good reason that it's *not* a bind mount, IMO. > > > > Yes, but /dev is already a bind-mount, so lfs *might* (I don't say it > will though) touch host's /dev/pts. Bind mounts don't follow sub mounts. (They aren't done at the file name level, they're done as a mount of the same underlying FS starting at a sub-path that it has. If that makes any sense.) So it can't with just the bind mount of /dev. > I do recall when I've done a chroot to arch system I have, and I just > mounted $chroot/dev/pts as was done before in lfs - mount -t devpts > devpts $chroot/dev/pts, it broke down my /dev/pts on a currently running > system That doesn't make a ton of sense to me, because it's not how that stuff works... What would happen if we used a different source string (not devpts), since that would fix the potential problem of both the host and the lfs system using the same (probably nonexistant) underlying device? > LFS does it correctly by setting correct mode and gid, but I still think > that this one should be a bind-mount. That's *guaranteed* to break when the host system uses a different gid though. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
