On Fri, Jan 08, Johannes Meixner wrote:
Hello,
On 2021-01-08 13:29, Martin Wilck wrote:
- other operating systems tend to put everything belonging to a certain "app" into a few app-specific directories. This is how /opt works, and from the 3rd party point of view, it makes a lot of sense. This is mostly about how to organize "data", I suppose. But still worth consideration.
I remember "good old MS-DOS times" where each application installed all of it (programs and date) below its own specific directory (regardless how that directory was named). So it was easy e.g. to see all what belongs to that application, how much disk space it wastes, and to get completely rid of it.
For this we have today package managers, who do provide the same functionality much nicer ;)
- privacy and encryption. with per-user encrypted $HOME, it makes sense to store other data belonging to the users in the same file system, like their mail spool or temporary files. World-writable /tmp should be obsolete; basically nothing except the user's own $HOME should be writable by the user. Data shared between users would live in special, separate area. Similar considerations would hold for services.
I like the Android idea to run different things under different accounts to get them separated.
That's what we call Container on Linux ;)
I would like to see that for Linux services in general (except exceptions like systemd). So each service would use its own user and home directory which is the only writable place for that account.
With MicroOS and containerized workload, this is already possible today. My router and servers are completly containerized, including a full mailserver setup including dovecot. And of course my nameserver, dhcp, etc. Only chrony is not containerized: chicken-egg problem, you need the correct time to pull a container.
I think for third-party software it would be also good: Each third-party software uses its own separated account and all what belongs to a third-party software is stored in the home directory of this separated account.
That's why even SAP is moving in the container direction :)
So a future filesystem standard should support such use cases.
The nice things about containers are: they don't care about your filesystem standard, as they are running outside of it.
By the way: The cupsd is a fine bad example of a service that runs as root (because sometimes it may need to do some exceptional stuff). About 15 years ago we let the cupsd run as user 'lp' which worked for all normal user's printing cases but we got many bad user complaints plus agressive rejection by upstream ('RunAsUser' got dropped by upstream in a minor release) so we gave up and let that thingy run as root since then. Nowadays one can cage that beast in a container. Wow - what great progress!
To be honest, I like a containerized cups running as "root" much more than having a cups running on my system as user "lp".
But I think traditional Unix style (like FHS and all what needs to do "important" things runs as root) will stay forever (except some big does all on its own like Google with Android).
FHS will not stay forever, FHS is dead, since"FHS upstream" refuses to do anything new. And "imprtant" things runs as root are luckily solveable. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)