Skip to main content ↑ ↓
Topic: All your home dir are belong to us (Read 2041 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: All your home dir are belong to us

Reply #15 –
Are there replacements for etmpfiles & esysusers?

Are there other things from systemd in Artix? I know that there is elogind.

Re: All your home dir are belong to us

Reply #16 –
Quote from: kiblaster – on
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.

Re: All your home dir are belong to us

Reply #17 –
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:
Code: [Select]
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)

Re: All your home dir are belong to us

Reply #18 –
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:
Quote
systemd-tmpfiles creates, deletes, and cleans up volatile and temporary files and directories, using the
configuration file format and location specified in tmpfiles.d(5). It must be invoked with one or more commands
--create, --remove, and --clean, to select the respective subset of operations.
Which again suggests it is all about volatile and temporary files and directories.
Only later in the description do we see:
Code: [Select]
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.

Re: All your home dir are belong to us

Reply #19 –
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
 

Re: All your home dir are belong to us

Reply #22 –
Quote from: gripped – on
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.

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)

Re: All your home dir are belong to us

Reply #23 –
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.

Re: All your home dir are belong to us

Reply #24 –
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?

Re: All your home dir are belong to us

Reply #25 –
Quote from: dpx – on
I am very interested in the results. It may turn out that apart from creating /home and similar folders it doesn't do much.
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
Code: [Select]
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
Code: [Select]
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
Quote
q /var 0755 - - -

L /var/run - - - - ../run

d /var/log 0755 - - -

d /var/cache 0755 - - -

d /var/lib 0755 - - -

d /var/spool 0755 - - -
So the first line says create a dir or subvolume /var
Even though it already exists,  upon running
Code: [Select]
etmpfiles --purge var.conf
systemd be like
Quote
All your /var are belong to us
And deletes the lot.

It's piss poor imho (aimed only at systemd)

Re: All your home dir are belong to us

Reply #27 –
Quote from: dpx – on
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?
Not the dev you asked for but on openrc it's called every boot by /etc/init.d/etmpfiles-setup
Code: [Select]
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
Code: [Select]
etmpfiles --exclude-prefix=/dev --create --remove --boot
Which will try and do this
Spoiler (click to show/hide)

Most of which it's a stretch to consider tmp or volatile other than /run /var/run and a few others.

Re: All your home dir are belong to us

Reply #29 –
@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
Code: [Select]
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 ;)