https://github.com/systemd/systemd/issues/33349
I skimmed the discussion there, and this statement by Lennart himself caught my eye:
Which sounds to me that systemd is headed towards... package management? And heck, why not! Maybe Arch will then drop pacman support as an unnecessary burden.
Artix is my first Linux operating system. I've read how bloated Systemd was and how it kept getting security vulnerabilities. So I decided to try out a non-Systemd system first and if it was "too hard" I'd just switch.
Open-RC is extremely easy to use. For an end user, starting/adding services is identical barring swapping the commands. I cannot fathom why the major Linux distros other than Gentoo don't offer multiple options for an init system now. The alternatives are probably easier to use at this point.
Regarding the specific issue itself, the highlight has got to be a guy named Bluca closing the issue only for Poettering himself to reopen it. Bluca works at Microsoft according to his Github so double funny.
What's really interesting though is this pull request Poettering made that got merged. It states that one of the fixes was for "--dry-run" not actually being a dry run of the command.
https://github.com/systemd/systemd/pull/33383 (https://github.com/systemd/systemd/pull/33383)
They also argue about Bluca (this guy seems fun at parties) pushing the commit too quickly without review from people involved with the issue. I mean deep down I know everyone only pretends to be professional but seeing a bunch of "nerds" for a lack of better word behave similarly is kind of funny.
The functionality of generating volumes/subvolumes and the like is really kind of cloud oriented and obviously only for experts.
I suppose the idea is that an 'instance' can be spun up with minimal user intervention and some genius decides which of the normal root folders get automatically generated. Some 'real' genius decided that since they were created as temp they were temp and not in any way permanent.
I must remember to make my home folder in /tmp and have /home/myhome just a symbolic link to it so I will soon be a systemd master :)
It's humiliation ritual at this point, they're also really quick to disable reactions on their messages, haha.
Poettering works for them as well. In case you didn't know.
I've got to admit I'd find the whole issue hilarious other than the fact that some unfortunate people may have lost important data.
I have no idea why any dirs under /home should be considered temporary and be handled by systemd-tmpfiles ?
Is this the standard in Arch these days or is it something you'd have to go out of your way to implement ?
They were arguing about Q versus q or something
$ cat /usr/lib/tmpfiles.d/home.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
Q /home 0755 - - -
q /srv 0755 - - -
A while ago I've read about this then-new "feature" of systemd where it would actually handle users' home dirs. Maybe it's connected?
This has opened a bit of a can of worms for me.
I was aware of esysusers and etmpfiles and that they were extracted from systemd in a similar fashion to elogind.
The only time I've looked any closer at etmpfiles was when the entry for lighttpd got changed in its package and I had to put an override in /etc/tmpfiles.d/lighttpd.conf to prevent a directory having it's permissions changed every time I rebooted (or possibly restarted lighttpd?)
I was unaware just how pervasive it's become.
etmpfiles --cat-config
shows all the files under the 'tmpfiles' umbrella and many of them are not temporary files.
In the interests of very unscientific science I just cloned my rootfs and on the clone
sudo rc-update del etmpfiles-setup boot
sudo rc-update del etmpfiles-dev sysinit
Rebooting seemed to have had no ill effect so far ? I expect problems would occur installing some packages, or at least running them, if the hook at /usr/share/libalpm/hooks/30-etmpfiles.hook was removed as well.
So it seems that whereas once programs used to setup there own files and dirs etc, or the package manager would do it, now it gets deferred to systemd-tmpfiles or etmpfiles on Artix ?
None of that was advice in anyway.
I enjoy breaking my system. And I've decided to learn more.
I guess it's related to this image:
This is super worrying to me, among other things is this segment:
# /usr/lib/tmpfiles.d/home.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See tmpfiles.d(5) for details
Q /home 0755 - - -
q /srv 0755 - - -
So /home is indeed referenced, right? I was trying to find anything that gentoo people think about this but couldn't find anything yet.
Who is currently upstream for etmpfiles? Gentoo people or somebody else?
Fixed by removing part of the documentation so we don't easily see that /home remains under systemd temp files control, this is the 'fix': https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a (https://github.com/bluca/systemd/commit/c4220bd2d390e9b330e835256182130d3bd5b94a)
This is equivalent of 'just' using systemd nntp client but then nntp client declares that /usr and /home belong to nntp service. I am really annoyed by this.
I don't think you need to worry too much so long as you don't run
etmpfiles --purge
for the brief period where this newly added --purge option deletes everything etmpfiles handles if no .conf is supplied as a argument.
But since the update to 256-1 this 'functionality' is present in Artix as well.
The upstream is systemd. Though etmpfiles & esysusers are part of the udev pkgbase.
You can view how they are built and packaged for Artix here (https://gitea.artixlinux.org/packages/udev/src/branch/master/PKGBUILD)
Gentoo does pretty much the same thing I believe but they just call it systemd-tmpfiles.
In the short run yes, systemd damage trough temp files is dormant, but can we detect if systemd decides to expand its grip and say change privileges or access rights on /home in five versions from now? Or move home files to some tempfs volume "because that's how it should be"? Most of the systemd crap is detected incidentally, including the one in this topic.
What I want to say is that even the smallest systemd part can do stuff that no sane person would assign to that part's role. I was really hoping that gentoo, considering greater manpower they have, do filter and check code in systemd-tmpfiles before using.
I'd argue that this functionality is not needed at all on Artix as long as distro maintainers do it manually - which I expect them to do since it's non-systemd. Also I read somewhere (but don't quote me on that!) among this chaos that tmpfiles is primarily needed for setting up system with only /usr/ as partition (???) and then everything is handled by this thing by doing filesystem layout virtually. Either way, I think that as long as you don't use that, we'll be fine, but then again who knows what microsoftd mafia implement next...
Are there replacements for etmpfiles & esysusers?
Are there other things from systemd in Artix? I know that there is elogind.
There was opentmpfiles https://github.com/OpenRC/opentmpfiles but it was retired since the tmpfiles can be extracted from systemd and is standalone. More details can be found here: https://github.com/OpenRC/opentmpfiles/issues/19
The biggest problem is that only a few people worked on a parallel implementation WHILE a lot of people work on systemd version and they do their own stuff without caring for the rest of the world. So, keeping up with their whims is hard and stuff are breaking.
You are welcome to resurrect opentmpfiles if you so wish for or even make your own project. If it will be on par with systemd implementation (in features, not bugs) Artix will surely offer it.
I'm wondering what are the "features" of etmpfiles we supposedly need to keep up with. Namely, I just took advantage of the new "--dry-run" option and checked what the etmpfiles commands actually do (on my openrc system).
For the
most part, it seems these scripts just ensure certain things that should be there are
still there, i.e., lets say a stupid user removes a critical file under /etc, then a factory default is plopped in place so that the system at least starts up. Kinda reminds me of how the cure to fix Windows (and Android!) is to reboot...
Many things that these scripts say they "would create" are files that pacman reports are owned by various packages, e.g. filesystem, so they're created upon system install and should still be there unless someone is toying around abusing sudo.
So adhering to the UNIX way of things, that a person with admin priviledges is supposed to know what they're doing, a replacement for etmpfiles would seem to be a very trivial script that hardly ever needs any maintenance. Again, what "features" are we talking about here? That factory default nonsense is not a feature I need! I want to be
allowed to break my system with my own stupidity!
For reference, here are the commands I tested:
etmpfiles --dry-run --prefix=/dev --create --boot
etmpfiles --dry-run --exclude-prefix=/dev --create --remove --boot
(as per the files in /etc/conf.d/, my "tmpfiles_opts" is empty)
I think one of the issues is that it's terribly named and badly documented.
'systemd-tmpfiles' and 'etmpfiles' hint that this is going to relate to temporary files.
Then reading the man page at the start of the description is:
Which again suggests it is all about volatile and temporary files and directories.
Only later in the description do we see:
System services (systemd-tmpfiles-setup.service, systemd-tmpfiles-setup-dev-early.service,
systemd-tmpfiles-setup-dev.service, systemd-tmpfiles-clean.service) invoke systemd-tmpfiles to create system
files and to perform system wide cleanup.
A lot of the .confs in /usr/lib/tmpfiles.d reference files and directories which a normal user would not consider volatile or temporary.
But if, as mentioned elsewhere in the thread, this functionality is aimed at 'cloud' servers and rapidly spun up and removed instances then I suppose it could be argued that every file under / is volatile or temporary.
I suspect that once upon a time systemd-tmpfiles did just concern itself with volatile and temporary files and directories.
And then in standard systemd fashion it was decided that systemd-tmpfiles should get involved in all your system files? And most bizarrely even your home dir.
Just a guess.
At some point soon I'm going to experiment with a artix-bootstrap install where I'll replace etmpfiles with a dummy package and then install all the packages I have installed on my normal system and see how much is broken with the lack of etmpfiles.
Not content with messing with /home etc etc systemd engineers have started to make old commands like df -h hard to use. I updated my work computer today and it has the latest systemd and I see that df -h now contains 19 entries most of which are credentials. I have poor eyesight so searching for a newly mounted usb has become harder.
Apparently this is something to do with credentials (https://unix.stackexchange.com/questions/778643/unexpected-tmpfs-mounts-please-explain)
I agree with your sentiment.
You could use
df -h -x tmpfs
to reduce the clutter.
thanks df -hx tmpfs reduces the count to 4 so much easier
I am very interested in the results. It may turn out that apart from creating /home and similar folders it doesn't do much.
Classical systemd takeover of simple tools/libs, endless feature creep and obscuring of what they do, than making them the only source of truth for the task.
I am not familiar with tmpfiles role, apart from what I read in the last few days, but I am programmer so I should be quick to understand the mechanics. Are they offering interface that is actively used by other apps or just working with its conf files and making sure that I have /home (d'oh) on the disk?
Edit: I just read initial documentation and, as suspected, systemd-tmpfiles executable just goes trough https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html# to create bunch of directories. In simpler words we are using this abomination as super complicated replacement for "mkdir".
Since my OpenRC never calls --clean (is this correct?), we don't even use cleaning side of the executable.
Just a glorified shell script with bunch of "cd <location> && mkdir <folder". Facepalm.
https://www.freedesktop.org/software/systemd/man/latest/systemd-tmpfiles.html
(If I am wrong please feel free to let me know)
There are apparently some complicated privilege escalation vulnerabilities with shell-script-only approaches to tmpfiles.d (seemingly the reason opentmpfiles was abandoned?). But that only pertains to some of the fancy features of the tmpfiles.d specification from freedesktop.org. I sure don't need any of those... The more I read about this stuff, the more I'm starting to question the sanity of the whole tmpfiles.d specification.
Now the Artix base package depends on etmpfiles, and this, if not completely superfluous, could surely be worked around without too much trouble.
Can some kind Artix dev tell me when does Artix call 'etmpfiles --create'? Is it on install only? Is there any scenario where this executable is called ever again?
If and when I get round to it I'll post the results here.
Even in the case of /home it's added by the package 'filesystem' so systemd-tmpfiles doesn't create it.
But in it's current state (256-1) it will decide it created anything that exists if referenced by a .conf file in one of the dirs that it searches eg /usr/lib/tmpfiles.d. Whether it actually created that file/directory or not.
On my system
etmpfiles --purge --dry-run
shows a list of 797776 files which would be removed including the entirety of /home & /var
Even with their fix in 256.1-1 It seems like a poor concept.
Now
etmpfiles --purge
will do nothing.
But a buggy package could install a buggy tmpfiles .conf file which will destroy your filesystem when the package is removed.
Or it could be done maliciously with an AUR package
/usr/lib/tmpfiles.d/var.conf
So the first line says create a dir or subvolume /var
Even though it already exists, upon running
etmpfiles --purge var.conf
systemd be like
And deletes the lot.
It's piss poor imho (aimed only at systemd)
Yet another reason I dropped using vanilla Arch in favor of Artix.
Not the dev you asked for but on openrc it's called every boot by /etc/init.d/etmpfiles-setup
start() {
ebegin "Setting up tmpfiles.d entries"
etmpfiles --exclude-prefix=/dev --create --remove --boot \
${tmpfiles_opts}
eend $?
}${tmpfiles_opts} is null (on my system) so this gets run
etmpfiles --exclude-prefix=/dev --create --remove --boot
Which will try and do this
# etmpfiles --dry-run --exclude-prefix=/dev --create --remove --boot [16:14:06]
Would remove "/tmp/.X0-lock".
Would create subvolume /var
Would create directory /var/lib
Would create directory /var/lib/alsa
Would copy tree "/usr/share/factory/etc/artix-release" to "/etc/artix-release"
Would copy tree "/usr/share/factory/etc/crypttab" to "/etc/crypttab"
Would copy tree "/usr/share/factory/etc/fstab" to "/etc/fstab"
Would copy tree "/usr/share/factory/etc/group" to "/etc/group"
Would copy tree "/usr/share/factory/etc/gshadow" to "/etc/gshadow"
Would copy tree "/usr/share/factory/etc/host.conf" to "/etc/host.conf"
Would copy tree "/usr/share/factory/etc/hosts" to "/etc/hosts"
Would copy tree "/usr/share/factory/etc/issue" to "/etc/issue"
Would copy tree "/usr/share/factory/etc/issue" to "/etc/issue"
Would copy tree "/usr/share/factory/etc/ld.so.conf" to "/etc/ld.so.conf"
Would copy tree "/usr/share/factory/etc/nsswitch.conf" to "/etc/nsswitch.conf"
Would copy tree "/usr/share/factory/etc/nsswitch.conf" to "/etc/nsswitch.conf"
Would copy tree "/usr/share/factory/etc/passwd" to "/etc/passwd"
Would copy tree "/usr/share/factory/etc/profile" to "/etc/profile"
Would copy tree "/usr/share/factory/etc/profile.d/locale.sh" to "/etc/profile.d/locale.sh"
Would copy tree "/usr/share/factory/etc/securetty" to "/etc/securetty"
Would copy tree "/usr/share/factory/etc/shadow" to "/etc/shadow"
Would copy tree "/usr/share/factory/etc/shells" to "/etc/shells"
Would copy tree "/usr/share/factory/etc/subuid" to "/etc/subuid"
Would copy tree "/usr/share/factory/etc/subgid" to "/etc/subgid"
Would copy tree "/usr/share/factory/etc/audit" to "/etc/audit"
Would copy tree "/usr/share/factory/etc/audisp" to "/etc/audisp"
Would copy tree "/usr/share/factory/etc/libaudit.conf" to "/etc/libaudit.conf"
Would create directory /var/log
Would create directory /var/log/audit
Would create directory /etc/credstore
Would create directory /etc/credstore.encrypted
Would create subvolume /srv
Would create directory /srv/deluge
Would create directory /run/dhcpcd
Would create symlink /etc/os-release -> ../usr/lib/os-release
Would create symlink /etc/mtab -> ../proc/self/mounts
Would copy tree "/usr/share/factory/etc/locale.conf" to "/etc/locale.conf"
Would copy tree "/usr/share/factory/etc/vconsole.conf" to "/etc/vconsole.conf"
Would create directory /var/lib/flood
Would create directory /var/lib/geoclue
Would create directory /run/gluster
Would create subvolume /home
Would create directory /var/lib/lastlog
Would create directory /run/lock
Would create symlink /var/lock -> ../run/lock
Would create directory /run/lock/subsys
Would create directory /run/lighttpd
Would create directory /var/cache
Would create directory /var/cache/lighttpd
Would create directory /run/lirc
Would create directory /var/cache/man
Would create directory /run/initramfs
Would create directory /run/multipath
Would create subvolume /var/lib/ollama
Would copy tree "/usr/share/factory/etc/pam.d/sshd" to "/etc/pam.d/sshd"
Would copy tree "/usr/share/factory/etc/ssh/moduli" to "/etc/ssh/moduli"
Would copy tree "/usr/share/factory/etc/ssh/ssh_config" to "/etc/ssh/ssh_config"
Would copy tree "/usr/share/factory/etc/ssh/sshd_config" to "/etc/ssh/sshd_config"
Would create directory /etc/ssh/sshd_config.d
Would copy tree "/usr/share/factory/etc/ssh/sshd_config.d/99-archlinux.conf" to "/etc/ssh/sshd_config.d/99-archlinux.conf"
Would create directory /etc/ssh/ssh_config.d
Would create directory /var/empty
Would create directory /run/faillock
Would create file /var/lib/power-profiles-daemon/state.ini
Would create directory /root
Would create directory /root/.ssh
Would create directory /var/lib/rpcbind
Would create directory /run/samba
Would create directory /var/log/samba
Would create directory /var/lib/sddm
Would create directory /run/sudo
Would create directory /run/sudo/ts
Would create directory /run/svnserve
Would create subvolume /tmp
Would create subvolume /var/tmp
Would create directory /var/lib/tpm2-tss/system/keystore
Would create directory /run/tpm2-tss/eventlog
Would create directory /run/uuidd
Would create directory /var/lib/libuuid
Would create symlink /var/run -> ../run
Would create directory /var/spool
Would create directory /tmp/.X11-unix
Would create directory /tmp/.ICE-unix
Would create directory /tmp/.XIM-unix
Would create directory /tmp/.font-unix
Would set default ACL u::rwx,g::rwx,g:tss:rwx,m::rwx,o::r-x on /var/lib/tpm2-tss/system/keystore
Would set default ACL u::rwx,g::rwx,g:tss:rwx,g:sddm:rwx,m::rwx,o::r-x on /run/tpm2-tss/eventlog
Would change "/sys/kernel/security/tpm0/binary_bios_measurements" to owner 0:964
Would change "/sys/kernel/security/tpm0/binary_bios_measurements" to mode 440
Most of which it's a stretch to consider tmp or volatile other than /run /var/run and a few others.
I saw in opentmpfiles issues pawprint (https://github.com/eweOS/pawprint) which is part of eweOS project that is "just another Linux distro" without systemd.
Not sure if they use it.
Others
https://github.com/juur/tmpfilesd
https://github.com/rust-torino/tmpfiles-rs
So udev is part of systemd too.
@dpx Surprisingly little broke.
What I did.
Mounted a new ext4 partition and ran artix-bootstrap to install a base openrc system on it.
(It should be noted that as part of the bootstrap etmpfiles & esysuser will be run once by their hooks)
chrooted to it and installed base-devel.
Built and installed this PKGBUILD
pkgname='eshitdummy'
pkgver=0.1
pkgrel=1
arch=(any)
provides=('etmpfiles' 'esysusers')
conflicts=('etmpfiles' 'esysusers')
Which after prompting removed etmpfiles & esysuser
Removed the rc-update entries for etmpfiles & esysuser
Made a list of all my installed native packages
Installed that list in the chroot.
Went through the files in the chroot's /usr/lib/sysusers.d and added users and groups manually where missing (I did have a list but lost it. From memory /usr/lib/sysusers.d/android-udev.conf , /usr/lib/sysusers.d/cups.conf , /usr/lib/sysusers.d/deluge.conf , libvirt , qemu, virtualbox
Created a user and copied my ~ dotfiles to it.
Rebooted and X & KDE started no problem. (startx)
Polkit wasn't working though.
Rsync'd my whole /etc to the test partition which meant it would now use my actual home partion from my fstab settings (Just had to switch the / UUID to the test partition.)
Booted into it again and now polkit worked. So I either cocked up creating the users and groups or there was something else missing from test's /etc. I think the latter as part of the polkit error was about a missing 'Magic Cookie' ?
Everything I tested worked. Network, video, audio, OBS video capture, printing, Virtualbox. Wine / Lutris based gaming.
So I'm just going to continue the experiment by removing etmpfiles & esysuser on my main install and seeing how I get on.
Disclaimer: Not good advice. I'm an idiot. I enjoy breaking my computer. No one should do this ;)
This is my biggest worry or to be more precise next tmpfiles upstream update that considers that /home should not be there and moves/encrypts/reformats it in the way that works with systemd but kills all non-systemd home folders. I mean why not, wouldn't be scariest thing that systemd did so far.
I am trying to imagine use-case where this is needed on every boot? If we would execute it on the first install and never again that would be controlled risk, running it on every boot is much bigger threat.
Does anybody knows, when pacman uninstalls package does it try to call etmpfiles --clean for that package? (I'll check pacman source in the few next days if we are not sure)
Yeah I'm with you. There is no way that systemd-tmpfiles has any business deleting files and dirs that the tmpfiles.d .conf files don't directly reference.
And they should be creating a database of the files/dirs they did create. Because if you didn't create it don't even consider deleting it and everything under it.
As a less drastic solution than I described above you could also just remove the more dangerous (imho) files eg home.conf var.conf from /usr/lib/tmpfiles.d and add the filenames to /etc/pacman.conf
NoExtract = usr/lib/tmpfiles.d/home.conf usr/lib/tmpfiles.d/var.conf
I think that's right ? Check the manpage
/usr/share/libalpm/hooks/30-etmpfiles.hook
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/tmpfiles.d/*.conf
[Action]
Description = Creating temporary files...
When = PostTransaction
Exec = /usr/bin/etmpfiles --create
So I don't think --clean gets called on installation or upgrade or removal ?
But I've removed the packages now, could be there was another hook ?
Great minds and all that... I am just looking into ways to sanitize tmpfiles reach, first thing was to move home.conf out of reach.
Maybe we can end with some solution like this (I'll need to do some more reading just to make sure nothing is missed) so etmpfiles can be patched on a package level. I'll clone udev PKGBUILD in a day or two to do some testing.
Another option is to create empty files in /etc/tmpfiles.d/ matching the names of the files in /usr/lib/tmpfiles.d you want to block / override.
I'm going to stick with my nuclear approach for now though.
"refuse systemd-tmpfiles --purge invocation..." :'(
This is a bit ridiculous since SysVinit knows how to handle this for a long time!
$ cat /etc/default/rcS
##################################################################
# NOTE: This file is ignored when systemd is used as init system #
##################################################################
#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.
# delete files in /tmp during boot older than x days.
# '0' means always, -1 or 'infinite' disables the feature
#TMPTIME=0