4 ms·

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 error

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.

glogla 9y ago
"Trolls" have not forced anythings - just standard systemd developer behavior. They never make mistakes and everything is someone elses fault. Systemd is running something as root because it doesn't like something in configuration file, instead of returning error or running it under the correct user. That's a huge WTF and a possible security issue, but alas. Systemd doesn't make mistakes and everything is someone elses fault.
- hahainternet 9y ago
  > "Trolls" have not forced anythings - just standard systemd developer behavior. They've had to delete multiple posts from the thread which are nothing but trolls, hell YOUR post is nothing but a troll.
  - rndgermandude 9y ago
    This is not true, I've seen the issue develop till it was closed. There were like 2 posts removed, 1 might have been trollish, the other(s) were just people voicing displeasure at general systemd dev behavior. That might be offtopic and not polite, but it's not a troll either. And the OP you're replying to falls into that snarky, impolite category too, but is not a troll.
    - digi_owl 9y ago
      sadly these days it is all too easy to stick fingers in ears and go "troll troll troll" or "hater hater hater" than actually introspect. Tempted to label it as a ripple effect of the rising SJW element in FOSS, because both terms seems to attract that group in defense of the shouter without concern for context.
subway 9y ago
root isn't the default -- the letters are being truncated, and the leading int used as a uid.
- Ded7xSEoPKYNsDd 9y ago
  If you read the whole bug, you'd see that's not true. The parse for a number fails, and therefore the directive is ignored (with a warning in the journal). Without a (valid) user setting, services are started as root.
michaelmrose 9y ago
This seems like a way simpler suggestion than what was discussed in the thread you ought to pass this on
zokier 9y ago
I think the problem with that idea is that there is no guarantee that the system actually has a "nobody" user. Uid0 is pretty much guaranteed to exist, others not so much. So in case of invalid User= line, I think root is the only safe fallback.
- viraptor 9y ago
  It's definitely not a safe fallback. It could be just rejected instead.
Mithaldu 9y ago
You can still respond by opening a new issue and referencing that one in it.
JdeBP 9y ago
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 as accounts that own vast tracts of the filesystem that the daemon programs have no business dealing in. * https://askubuntu.com/a/674397/43344 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 It is what Upstart does, as well: * https://bugs.launchpad.net/upstart/+bug/1165013 https://bugs.launchpad.net/upstart/+bug/1165013
- the_mitsuhiko 9y ago
  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.
  - JdeBP 9y ago
    No; I have just explained why nobody is unsuitable. Please bring yourself up to date and learn better. This is stuff that the world learned was the wrong thing to do in the 1990s. (The note in the LSB recommending against running daemons in a single shared account dates from 2002, and that was years late to the party.)

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.

glogla 9y ago

"Trolls" have not forced anythings - just standard systemd developer behavior. They never make mistakes and everything is someone elses fault. Systemd is running something as root because it doesn't like something in configuration file, instead of returning error or running it under the correct user. That's a huge WTF and a possible security issue, but alas. Systemd doesn't make mistakes and everything is someone elses fault.

hahainternet 9y ago
> "Trolls" have not forced anythings - just standard systemd developer behavior. They've had to delete multiple posts from the thread which are nothing but trolls, hell YOUR post is nothing but a troll.
- rndgermandude 9y ago
  This is not true, I've seen the issue develop till it was closed. There were like 2 posts removed, 1 might have been trollish, the other(s) were just people voicing displeasure at general systemd dev behavior. That might be offtopic and not polite, but it's not a troll either. And the OP you're replying to falls into that snarky, impolite category too, but is not a troll.
  - digi_owl 9y ago
    sadly these days it is all too easy to stick fingers in ears and go "troll troll troll" or "hater hater hater" than actually introspect. Tempted to label it as a ripple effect of the rising SJW element in FOSS, because both terms seems to attract that group in defense of the shouter without concern for context.

subway 9y ago

root isn't the default -- the letters are being truncated, and the leading int used as a uid.

Ded7xSEoPKYNsDd 9y ago
If you read the whole bug, you'd see that's not true. The parse for a number fails, and therefore the directive is ignored (with a warning in the journal). Without a (valid) user setting, services are started as root.

michaelmrose 9y ago

This seems like a way simpler suggestion than what was discussed in the thread you ought to pass this on

zokier 9y ago

I think the problem with that idea is that there is no guarantee that the system actually has a "nobody" user. Uid0 is pretty much guaranteed to exist, others not so much. So in case of invalid User= line, I think root is the only safe fallback.

viraptor 9y ago
It's definitely not a safe fallback. It could be just rejected instead.

Mithaldu 9y ago

You can still respond by opening a new issue and referencing that one in it.

JdeBP 9y ago

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 as accounts that own vast tracts of the filesystem that the daemon programs have no business dealing in. * https://askubuntu.com/a/674397/43344 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 It is what Upstart does, as well: * https://bugs.launchpad.net/upstart/+bug/1165013 https://bugs.launchpad.net/upstart/+bug/1165013

the_mitsuhiko 9y ago
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.
- JdeBP 9y ago
  No; I have just explained why nobody is unsuitable. Please bring yourself up to date and learn better. This is stuff that the world learned was the wrong thing to do in the 1990s. (The note in the LSB recommending against running daemons in a single shared account dates from 2002, and that was years late to the party.)