Message ID | 20200605224858.12870-2-nolange79@gmail.com |
---|---|
State | Accepted |
Headers | show |
Series | [1/2] Makefile: remove /usr/lib/rpm directory on target | expand |
Hello, On Sat, 6 Jun 2020 00:48:57 +0200 Norbert Lange <nolange79@gmail.com> wrote: > Scripts in the fakeroot environment could call > tools preparing the early environment, leaving > traces in /run or /tmp. > > mkusers might create home directories in /run for > example. > > Signed-off-by: Norbert Lange <nolange79@gmail.com> Looping Yann on this. I agree that we definitely want /tmp and /run to be empty, as we are anyway going to mount a tmpfs over them, so whatever they contains is not visible on the target system, but takes up some space on the filesystem. However, I'm not sure if removing all what they contain is the right approach. Shouldn't we avoid creating things in /tmp and /run in the first place ? Yann, any feedback on this ? Thomas
Am Sa., 6. Juni 2020 um 22:42 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > Hello, > > On Sat, 6 Jun 2020 00:48:57 +0200 > Norbert Lange <nolange79@gmail.com> wrote: > > > Scripts in the fakeroot environment could call > > tools preparing the early environment, leaving > > traces in /run or /tmp. > > > > mkusers might create home directories in /run for > > example. > > > > Signed-off-by: Norbert Lange <nolange79@gmail.com> > > Looping Yann on this. I agree that we definitely want /tmp and /run to > be empty, as we are anyway going to mount a tmpfs over them, so > whatever they contains is not visible on the target system, but takes > up some space on the filesystem. > > However, I'm not sure if removing all what they contain is the right > approach. Shouldn't we avoid creating things in /tmp and /run in the > first place ? Yeah we should avoid creating stuff there, but it's sometimes hard to do. One example is defining a user with home dir in /run, mkusers will then create a dir there (pretty late to clear it up otherwise) More important would be tools that lazily create stuff on the first boot, and either buildroot or a custom fakeroot stage script would run this on the host instead (worstcase in some sort of container/chroot). > > Yann, any feedback on this ? > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Norbert
On Sun, 7 Jun 2020 00:57:23 +0200 Norbert Lange <nolange79@gmail.com> wrote: > > However, I'm not sure if removing all what they contain is the right > > approach. Shouldn't we avoid creating things in /tmp and /run in the > > first place ? > > Yeah we should avoid creating stuff there, but it's sometimes hard to do. > One example is defining a user with home dir in /run, mkusers will > then create a dir there > (pretty late to clear it up otherwise) But our skeleton has a fstab that always mounts a tmpfs filesystem on /run, so how can it make sense for mkusers to create a home directory in /run ? Thomas
Am So., 7. Juni 2020 um 10:47 Uhr schrieb Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > > On Sun, 7 Jun 2020 00:57:23 +0200 > Norbert Lange <nolange79@gmail.com> wrote: > > > > However, I'm not sure if removing all what they contain is the right > > > approach. Shouldn't we avoid creating things in /tmp and /run in the > > > first place ? > > > > Yeah we should avoid creating stuff there, but it's sometimes hard to do. > > One example is defining a user with home dir in /run, mkusers will > > then create a dir there > > (pretty late to clear it up otherwise) > > But our skeleton has a fstab that always mounts a tmpfs filesystem on > /run, so how can it make sense for mkusers to create a home directory > in /run ? Think of system users, where the "home" is usually non-persistent or just some sort of jail. For ex. my openssh patch sets the sshd user's home to /run/sshd - A directory that's automatically created when the service starts and deleted when it stops. > > Thomas > -- > Thomas Petazzoni, CTO, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Norbert
Am So., 7. Juni 2020 um 20:41 Uhr schrieb Norbert Lange <nolange79@gmail.com>: > > Am So., 7. Juni 2020 um 10:47 Uhr schrieb Thomas Petazzoni > <thomas.petazzoni@bootlin.com>: > > > > On Sun, 7 Jun 2020 00:57:23 +0200 > > Norbert Lange <nolange79@gmail.com> wrote: > > > > > > However, I'm not sure if removing all what they contain is the right > > > > approach. Shouldn't we avoid creating things in /tmp and /run in the > > > > first place ? > > > > > > Yeah we should avoid creating stuff there, but it's sometimes hard to do. > > > One example is defining a user with home dir in /run, mkusers will > > > then create a dir there > > > (pretty late to clear it up otherwise) > > > > But our skeleton has a fstab that always mounts a tmpfs filesystem on > > /run, so how can it make sense for mkusers to create a home directory > > in /run ? > > Think of system users, where the "home" is usually non-persistent or > just some sort of jail. > For ex. my openssh patch sets the sshd user's home to /run/sshd - A > directory that's automatically > created when the service starts and deleted when it stops. > Some other example is dbus, creates a user with homedir=/var/run/dbus. So not only my hackjobs are affected ;) Should I somehow ping you if some patches are ready BTW (not sure if you read through all discussions)? On that note, can you upgrade fakeroot to 1.24 now? https://patchwork.ozlabs.org/project/buildroot/list/?series=176013 Norbert
Hi Norbert, On 06/06/2020 00:48, Norbert Lange wrote: > Scripts in the fakeroot environment could call > tools preparing the early environment, leaving > traces in /run or /tmp. > > mkusers might create home directories in /run for > example. > > Signed-off-by: Norbert Lange <nolange79@gmail.com> I finally applied to master, thanks. I extended the commit message based on the discussion on the patch. Regards, Arnout > --- > fs/common.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/common.mk b/fs/common.mk > index 842ea924a5..a5c6b4ea96 100644 > --- a/fs/common.mk > +++ b/fs/common.mk > @@ -171,6 +171,7 @@ $$(BINARIES_DIR)/$$(ROOTFS_$(2)_FINAL_IMAGE_NAME): $$(ROOTFS_$(2)_DEPENDENCIES) > > $$(foreach hook,$$(ROOTFS_$(2)_PRE_GEN_HOOKS),\ > $$(call PRINTF,$$($$(hook))) >> $$(FAKEROOT_SCRIPT)$$(sep)) > + echo "rm -rf $$(TARGET_DIR)/run/* $$(TARGET_DIR)/run/.[^.]* $$(TARGET_DIR)/tmp/* $$(TARGET_DIR)/tmp/.[^.]*" >> $$(FAKEROOT_SCRIPT) > $$(call PRINTF,$$(ROOTFS_REPRODUCIBLE)) >> $$(FAKEROOT_SCRIPT) > $$(call PRINTF,$$(ROOTFS_$(2)_CMD)) >> $$(FAKEROOT_SCRIPT) > chmod a+x $$(FAKEROOT_SCRIPT) >
diff --git a/fs/common.mk b/fs/common.mk index 842ea924a5..a5c6b4ea96 100644 --- a/fs/common.mk +++ b/fs/common.mk @@ -171,6 +171,7 @@ $$(BINARIES_DIR)/$$(ROOTFS_$(2)_FINAL_IMAGE_NAME): $$(ROOTFS_$(2)_DEPENDENCIES) $$(foreach hook,$$(ROOTFS_$(2)_PRE_GEN_HOOKS),\ $$(call PRINTF,$$($$(hook))) >> $$(FAKEROOT_SCRIPT)$$(sep)) + echo "rm -rf $$(TARGET_DIR)/run/* $$(TARGET_DIR)/run/.[^.]* $$(TARGET_DIR)/tmp/* $$(TARGET_DIR)/tmp/.[^.]*" >> $$(FAKEROOT_SCRIPT) $$(call PRINTF,$$(ROOTFS_REPRODUCIBLE)) >> $$(FAKEROOT_SCRIPT) $$(call PRINTF,$$(ROOTFS_$(2)_CMD)) >> $$(FAKEROOT_SCRIPT) chmod a+x $$(FAKEROOT_SCRIPT)
Scripts in the fakeroot environment could call tools preparing the early environment, leaving traces in /run or /tmp. mkusers might create home directories in /run for example. Signed-off-by: Norbert Lange <nolange79@gmail.com> --- fs/common.mk | 1 + 1 file changed, 1 insertion(+)