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 should also be bind-mounted, as it will override default devpts >>> flags and permissions which were mounted before. >>> >>> In my case: >>> >>> mount output before mounting devpts at $LFS/dev/pts >>> >>> 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. > >> Only root can create files in the devpts filesystem anyway (the >> directory post mount is 0755 root/root), so users can't add setuid or >> executable files anyway. And the filesystem contents can't be persisted >> anyway (it's not like a CD or USB drive, which might have the "user" >> option present, allowing users to attach arbitrary files to the system), >> so that's not a vector for introducing setuid or executable files >> either. >> >> Seems like trying to restrict root isn't the best idea. :-) >> >>> 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. > > 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 and I couldn't run any terminal emulator :( > > LFS does it correctly by setting correct mode and gid, but I still think > that this one should be a bind-mount.
I don't have a problem with making it a bind-mount. I suspect you have, but would like to confirm that a test build using it went OK. >>> In some cases, >>> tty gid could be different >> >> This is about the only potential issue. However, the /etc/group file >> that's about to be created in the book at this point does definitely >> assign tty to gid 5, so inside the chroot, /dev/pts will definitely be >> correct regardless of the host group assignment. >> >> ...And in fact, I think that's another reason to avoid a bind mount. If >> the host assigns tty to gid 4, then the bind mount will be broken inside >> chroot, since glibc will require it to be 5 in there. >> >>> Furthermore, I think that /run should also be mounted when building lfs, >>> since that is meant to be a tmpfs too, but some packages might install >>> files in there. In my current test full build, not booted, I have: $ ls /mnt/lfs/run -Rl /mnt/lfs/run: total 12 drwxr-xr-x 2 root root 4096 Dec 12 21:47 blkid drwxr-xr-x 2 root root 4096 Dec 12 21:51 mount drwxr-xr-x 2 root root 4096 Dec 12 18:49 shm /mnt/lfs/run/blkid: total 16 -rw-r--r-- 1 root root 4397 Dec 12 21:47 blkid.tab -rw-r--r-- 1 root root 4401 Dec 12 21:46 blkid.tab.old /mnt/lfs/run/mount: total 0 -rw-r--r-- 1 root root 0 Dec 12 21:51 utab -rw-r--r-- 1 root root 0 Dec 12 21:51 utab.lock /mnt/lfs/run/shm: total 0 Checking my logs, it appears that all these are created by the e2fsprogs regression tests. The run directory should be empty before rebooting, but it does not create any problem if it's not. I'm not sure if the best approach is to mount a separate tmpfs on /run in Chapter 6 or just rm -r /run/* in the Cleaning Up section (6.66). -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
