Le 23/03/2020 à 03:49, Bruce Dubbs via blfs-dev a écrit : > On 3/22/20 9:25 PM, Xi Ruoyao via blfs-dev wrote: >> On 2020-03-23 01:44 +0000, Ken Moffat via blfs-dev wrote: >>> On Mon, Mar 23, 2020 at 09:12:18AM +0800, Xi Ruoyao via blfs-dev wrote: >>>> On 2020-03-22 21:34 +0000, Ken Moffat via blfs-dev wrote: >>>> >>>>> # mount --bind /run /mnt/lfs/run >>>> >>>> I think it's dangerous: potentially harmful to the host. Some service >>>> running >>>> in the LFS chroot may overwrite the runtime directory of the service >>>> running >>>> on >>>> the host. >>> >>> So, you are saying that packages from mozilla should not now be >>> built in chroot ? >> >> No. I think we need a better way. >> >>> But, what do you mean by a service running in chroot ? I assume we >>> are specifically talking of systemd here ? Do services not get >>> started during the boot process ? The systemd instance in chroot >>> has never started, so I assume it will be ineffective and systemd on >>> the host will only care about services described in /etc/systemd ? >> >> Maybe that's not a issue. But still, /run contains lots of sockets of >> running >> services. That means now we can connect host services from the chroot >> environment. Even if it's not dangerous to host, it's polluting the new LFS >> system. >> >> Consider /run/initctl. We don't want something in chroot to switch the >> *host* >> to runlevel 1 :). > > What about > > mount -t tmpfs /run > > from within chroot? > > -- Bruce
FWIIW, here are my findings: On a debian host, we have: lrwxrwxrwx 1 root root 8 mars 26 09:48 /run/shm -> /dev/shm drwxrwxrwt 2 root root 40 mars 26 11:02 /dev/shm But when mounting /dev to $LFS with mount --bind, we have drwxr-xr-x 2 root root 40 mars 26 11:01 /mnt/lfs/dev/shm that is, the sticky bit and the write perm are lost for an average user. Now trying to build FF in chroot (creating kernel virtual filesystems and chrooting with the lfs book instructions): - as root: needs to issue "export SHELL", but otherwise succeeds without anything else (/run exists as a tmpfs , but /run/shm does not exist) - as user: no need to run "export SHELL" (I guess "su - <user>" does the export), but the perms to /dev/shm need to be changed to rwt In both cases, the build goes to completion (not tried to install) after the indicated changes. Another check I've done: on a lfs system (9.1-rc1 Sys V) as per the book, /dev/shm is drwxrwxrwt, and /run/shm does not exist. But everybody knows it is possible to build firefox Actually, if you just mount a devtmpfs: mkdir tempdir-for-trying-something sudo mount -t devtmpfs devtmpfs tempdir-for-trying-something ls -ld tempdir-for-trying-something/shm then the shm perms are drwxrwxrwt. So I'd suggest our instructions be changed to mount a devtmpfs in $LFS/dev But what makes me think I do something different from ĸen is that I never see: OSError: [Errno 38] Function not implemented Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
