51–60 of 63 posts
Sadly trolls already forced the issue locked but i feel like a sensible thing to do would be to keep that behavior but change the default user for parsing errors from root to nobody.
Sadly trolls already forced the issue locked but i feel like a sensible thing to do would be to keep that behavior but change the default user for parsing errors from root to nobody.
nobody is not a suitable account for running daemons as. It has a very specific purpose, originating in NFS. That purpose is to be the visible owner of files and directories in mounted NFS filesystems in certain circumstances. Daemon processes in general run as unprivileged accounts that should own a minimal amount of filesystem entities relevant to their operation. They certainly should not run as accounts that own vast tracts of the filesystem that the daemon programs have no business dealing in.
* https://askubuntu.com/a/674397/43344
For best results, a daemon process that has dropped privileges should run under the aegis of an unprivileged account that is a rôle account specific to that one service. This allows one to grant filesystem access and object ownership specifically, and enables the kernel's usual mechanisms for preventing other (unprivileged) processes from messing with the daemon process with the likes of ptrace() and kill().
And if the account given as the one to drop privileges to does not exist in the user account database and is invalid, the service should fail to run.
This is what daemontools-family service management does; because setuidgid (or runuid, or chpst, or whatever) abends with a fatal error when it fails to find the account in the system's account database. This is what the Solaris SMF does, too. It switches the service to the "maintenance" state when the "user" property for the method context is wrong:
Nov 12 22:24:17 aocdbs02a inetd[1053]: Property 'user' of instance svc:/network/stdiscover:default is missing, inconsistent or invalid
Nov 12 22:24:17 aocdbs02a inetd[1053]: Invalid configuration for instance svc:/network/stdiscover:default, placing in maintenance
Sadly trolls already forced the issue locked but i feel like a sensible thing to do would be to keep that behavior but change the default user for parsing errors from root to nobody.
Your idea is wrong. nobody is not a suitable account for running daemons as. It has a very specific purpose, originating in NFS. That purpose is to be the visible owner of files and directories in mounted NFS filesystems in certain circumstances. Daemon processes in general run as unprivileged accounts that should own a minimal amount of filesystem entities relevant to their operation. They certainly should not run a…
Earlier quoted context omitted.
In that case the systemd developers ought to have been thinking «usernames beginning with digits do exist in the wild on linux systems, therefore we should support them».
They just would have had to think "let’s do the safe thing — instead of just assuming everything goes well and potentially using the root user as fallback if we’re wrong". It’s a mindset/philosophy problem, and that doesn’t change when bugs get fixed. It would require the devs to change, but that didn’t happen in the past decade, so we cannot just assume that it will happen in the next.
Earlier quoted context omitted.
They just would have had to think "let’s do the safe thing — instead of just assuming everything goes well and potentially using the root user as fallback if we’re wrong". It’s a mindset/philosophy problem, and that doesn’t change when bugs get fixed. It would require the devs to change, but that didn’t happen in the past decade, so we cannot just assume that it will happen in the next.
But you have to be root to install a systemd unit in the first place...
EDIT: No; it acts as if the 'User=' directive doesn't exist.
Earlier quoted context omitted.
Your idea is wrong. nobody is not a suitable account for running daemons as. It has a very specific purpose, originating in NFS. That purpose is to be the visible owner of files and directories in mounted NFS filesystems in certain circumstances. Daemon processes in general run as unprivileged accounts that should own a minimal amount of filesystem entities relevant to their operation. They certainly should not run a…
It is a suitable user and has been used to run daemons for a long time. That it's not the ideal choice should be obvious.
Earlier quoted context omitted.
> POSIX says usernames starting with a digit should be fine. I'm not sure if POSIX has any relevance here. Afaik systemd isn't claiming any sort of POSIX compliance, nor is it targeting POSIX systems in general, in fact it is explicitly Linux-only.
Yes I tried to do research on this on the past. Linux, as in "just the kernel", doesn't care about user name formats as far as I can tell. However, the Linux philosophy goes "try to adhere to POSIX where it makes sense, break it where we think it sucks", which isn't exactly a clear statement, but lead me to conclude that it might make sense to check what posix does, if anything, because everything else is user space,…
Similarly they will retain previously introduced, but flawed, interfaces etc until they are damn sure that they are no longer in use.
Earlier quoted context omitted.
They just would have had to think "let’s do the safe thing — instead of just assuming everything goes well and potentially using the root user as fallback if we’re wrong". It’s a mindset/philosophy problem, and that doesn’t change when bugs get fixed. It would require the devs to change, but that didn’t happen in the past decade, so we cannot just assume that it will happen in the next.
But you have to be root to install a systemd unit in the first place...
What is going on here is that an admin thinks he has shored up the service defined in the service file, because hey, it runs. Only to later have the server 0wned because apparently it was running as root the whole time...
Earlier quoted context omitted.
Strict validation. If some option is not valid, fail loudly. And he still fails to acknowledge this is a security issue. Here's a scenario for you: You're running a SaaS which spawns restricted demons/containers per customer, separating the users by assigning them local user accounts. One day, user "0zero" registers and their account has access to your whole environment. Would you expect this? Would you not classify…
Or maybe 0pointer → http://0pointer.net/imprint