Systemd can't handle the process privilege for username startswith number | Hacker News Reader

Systemd can't handle the process privilege for username startswith number

github.com

92 pointsedward61 comments

I'm less and less surprised by the hate poettering gets. It's like he's deliberately trying to be as arrogant and ignorant as possible. POSIX says usernames starting with a digit should be fine. But because very few utils have more restrictive rules, systemd arbitrarily follows them too, but reacts in the most idiotic way possible if it considers a username invalid. Like last time, when in his opinion, "rm -rf *" should have ascended into ".." and shredded the whole file system, just like some systemd tool does. A bug? Usability issue? No way. What the fuck is wrong with this guy? Since day one of systemd he rallies the world advocating how all the existing init systems are convoluted, full of hacks, hard to maintain while systemd is clean and elegant, and then he seriously defends these insanely stupid unintuitive behaviors? I just don't get it.

> 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.

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.

But you have to be root to install a systemd unit in the first place...

There are also user-level unit files; can this bug be triggered by those?

EDIT: No; it acts as if the 'User=' directive doesn't exist.

And?

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...

Doesn't mean I want systemd silently escalating my process to root when I think I've told it to contain privileges of the process to a specific userid. Clearly the correct behavior for such a program is to throw an error if it is rejecting a username for ANY reason, even when that reason is supported by stilted reasoning.

Breaking expectations is not a reasonable default.

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, e.g. GNU (coreutils, adduser) and thus isn't tied to Linux. systemd should call into libc and let it deal with the username, so if any of the nsswitch backends think 0day is a valid username and returns a uidnumber, just use it and don't try to be extra clever.

Best i recall, the kernel will offer POSIX compliant interfaces, but then also offer parallel interfaces that fix potential problems.

Similarly they will retain previously introduced, but flawed, interfaces etc until they are damn sure that they are no longer in use.

Are you reading the same thread as me? He replied explaining precisely why this is an error and received nothing but hate for it, 40 thumbs downs.

On the other hand, you come here to uselessly complain and have the temerity to complain that poettering doesn't write exactly the code you want him to write.

How do you justify your ridiculous attitude?

Except it's less than clear that this is an "invalid username", as the following comments discuss. (even leaving out things like "defaulting to root")

> Except it's less than clear that this is an "invalid username"

Indeed, and once that was pointed out his response was equally polite and accurate, offering a workaround which keeps everyone happy.

Literally, what more do people expect?

The thing not being closed as "not a bug" before the situation is figured out (e.g. the opener had a user account starting with a 0, so it could be expected input) or clearer context is given (e.g. if systemd had an established policy on what a username is allowed to be, a reference to that)?

While understandable (maintainers are busy people and likely have to deal with a lot of reports that have clear cut answers), it sadly fits into the image people have of them.

I personally think "thumbs down" (since you referenced those) is a completely valid response to that – but to be clear, posting insults or other attacks is not!

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 this as a security issue?

I am going with ...

    root # chpst -u 0zero id
    uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
    root # setuidgid 0zero id
    uid=1462(0zero) gid=1481(0zero) groups=1481(0zero)
    root #

... I would not; I would. Both of these use the getpwnam() library function of course. Their behaviours are ...

    root # chpst -u 0day id
    chpst: fatal: unable to get password/group file entry: file does not exist
    root # setuidgid 0day id
    setuidgid: FATAL: 0day: No such user.
    root #

... to abend when the account name is not found rather than continue on as the superuser without dropping privileges ...

* http://jdebp.eu./Softwares/nosh/guide/setuidgid.html

* http://cr.yp.to/daemontools/setuidgid.html

* http://untroubled.org/daemontools-encore/setuidgid.8.html

... as is documented in their user manuals, resulting in ...

    root # system-control convert-systemd-units ./0day.service
    root # install -d /home/0day
    root # ln -s /etc/service-bundles/services/sysinit-log 0day/log
    root # system-control start 0day 
    root # system-control status 0day
    /var/local/sv/0day: 
            State   : failed since 2017-07-02 11:14:17 +0100; 0s ago
            Main PID: 80083
             Started: exit 0 at 2017-07-02 11:13:35 +0100; 42s ago
                 Ran: exit 111 at 2017-07-02 11:14:17 +0100; 0s ago
            Config  : enabled
    2017-07-02 11:14:17.130870725 setuidgid: FATAL: 0day: No such user.
    2017-07-02 11:14:17.247334398 setuidgid: FATAL: 0day: No such user.
    2017-07-02 11:14:17.363857132 setuidgid: FATAL: 0day: No such user.
    2017-07-02 11:14:17.481175128 setuidgid: FATAL: 0day: No such user.
    2017-07-02 11:14:17.598958702 setuidgid: FATAL: 0day: No such user.
    root #

... the 0day service from the headlined bug report failing to start.

Or maybe 0pointer → http://0pointer.net/imprint

He seems to prefer various alcoholic drinks when posting not posting under his own name though...

Defaulting to root? Spawning a service defaults to .. the current user.

We can argue if User= lines should be validated more carefully or cause hard errors (vs warnings), but if you do not provide a valid User= line, the process will spawn with the current uid (which is 0 for initd).

Tempted to say it's a service, and the majority of these will want to run as root instead of any particular user. So in this sense the default makes sense.

So if someone spawns the torrent server as a restricted user to add a layer of security against problems in the server, and that user starts with a zero — like 0priviledge or 0pointer for that matter, do mind the domain of L. Pötterings blog — the service will launch as root, voiding the layer of protection?

Many of my services do not run as root for a reason.

You are erroneously conflating the default when there is no User= item with the default when there is a User= item but its value is neither a number nor a valid account in the user account database. The latter default is the item under discussion here.

In this case there seem to be three bad design decisions:

systemd rejects usernames starting with a digit even though they exist in the wild;

systemd ignores config lines containing values it considers invalid, rather than failing the whole unit;

systemd defaults User to root, rather than making User required.

Any of those might be defensible on their own, but the combination is horrid.

Are you reading the same thread as me? He replied explaining precisely why this is an error and received nothing but hate for it, 40 thumbs downs.

No, apparently I'm not. In the thread I read, OP mentioned a regex that he found somewhere on the internet, and poettering just confirms it would be invalid. No references who says it's invalid or where to look up the definition. Nothing. Also no mention of the "default to root" issue in his post, which clearly could be considered a security issue as mentioned in several comments on the issue and here in the comments. He says config options are validated to prevent mistakes, but doesn't give any insight why anyone would consider default to root a sane fallback. You call that "explaining precisely"?

On the other hand, you come here to uselessly complain and have the temerity to complain that poettering doesn't write exactly the code you want him to write.

I gave examples of his contradictory behaviour regarding usability and dangerous pitfalls while claiming systemd would be elegant and easy to use. I'm not complaining he doesn't write code I want, I'm complaining he doesn't practice what he preaches and--as stated by the very first phrase of my comment--to explain why it doesn't come as much of a surprise to me he gets so much hate.

I've been working with systemd since late 2012 and like a lot of its ideas and concepts, but the way this guy deals with bug reports and people is just horrible.

How do you justify your ridiculous attitude?

Oh well, guess I just fed the troll by replying.

I think you're a bit too harsh.

If you maintain widely-used software, you're going to get a lot of bug reports which are in fact user error, and you don't have a great deal of time to spend on each report.

So it's easy to mistakenly dismiss a report when it contains at least one user error, or even something close to a user error, even when it also exposes a real bug.

(It's less forgivable to continue being loudly wrong once other people have pointed out real problems more clearly.)

I think you're a bit too harsh.

Yes, that might be true. I never complained about him before "in public" so there was some steam to release. However I hope I still gave enough clear thought on how I think he is acting wrong repeatedly.

(It's less forgivable to continue being loudly wrong once other people have pointed out real problems more clearly.)

Which only makes it worse. There is a good deal of serious replies to the issue, but because of some trolling, the whole discussion is considered invalid by the maintainers, or at least they make it look like that by just closing it without any further comment. Only about an hour ago did poettering reply again giving some more insight, but the damage has been done and next time there will probably be even more trolling.

I don't understand how this could be considered not a bug. Clearly, the unit was intended to run as 0day, not root. I must be missing something.

The rationale seems to be: "you're going to run into a lot of other software that'll also fail". He mentions xinetd as an example.

No, xinetd is mentioned as an example of software which accepts digit-prefixed username without issues. (Both by the reporter and by Pottering)

Hm, that seems like a strange rationale. "The other fail so we should, too?" That's not the guide I use for my software.

> I must be missing something.

A 0day is supposed to get you root access, so behaviour is working as expected.

Bugs are when software runs in a way other than the way the software is intended to run by the developer.

If you define "usernames starting with numbers" as invalid, and then define the behaviour of unit files with a user directive containing an invalid user to run as root, then the behaviour is as expected, and is not a bug.

The fact the software doesn't do what any sensible user would expect is completely irrelevant to it being a "bug" or not.

[edit: removed dig at poettering]

> The fact the software doesn't do what any sensible user would expect is completely irrelevant to Poettering.

Logs and error and continues? I think you're confused by Systemd exposing all sorts of frailties of traditional software. How do you propose that it differentiate between UIDs and user names?

While I am largely on the systemd side - that one is easy.

Make User= only accept input that starts with a character. Add another option for Uid= that would only accept numeric digits.

>How do you propose that it differentiate between UIDs and user names?

Maybe follow GNU coreutils, prefix ids with + https://www.gnu.org/software/coreutils/manual/html_node/Disa...

I wasn't really asking for a suggestion, more pointing out that it isn't some previously solved and agreed upon issue.

It's something that has to be picked, and the parent poster will undoubtedly count as 'arrogance' for choosing a workaround.

Use UserName and UserID instead of User?

By using a different setting name for UIDs and usernames, or by prepending UIDs with a +, or...

That's not the problem, though. The problem is that systemd encounters a username setting, and the workaround decided upon was that if you find an explicitly stated username setting, that the best thing to do in the case of that explicity stated username being something you consider invalid (despite it being completely valid on the largest platform you target) is to throw that statement away and proceed as the highest privileged user on the system, even though the very intent of the username setting is often to restrict privileges. It tells you about it in a log file, though, that you'll definitely see before it's too late!

Even that poorly thought out situation being the status quo isn't the problem. The problem is refusing to consider that this is perhaps not the best workaround, prior to this workaround becoming a de facto standard embedded by practice.

This isn't an us-versus-them thing. It's not about being combative or saying that anyone is wrong or bad. It's about looking for continual improvement.

It could treat all-digit values differently to values that just start with a digit.

Hm, seems as if this is what I was missing. I was on the sensible side.

The troubling thing here is the reaction of the systemd developer's of "invalid input, so won't fix". Even if the input is invalid (and that's not at all clear) in what world is "lol you're root now" a reasonable response?

from https://github.com/systemd/systemd/issues/6237#issuecomment-...

Why he said 0day not valid user?

I create '0day' user on my computer without problem (Fedora 26 Beta, Debian 9)

useradd 0day $ id 0day uid=1003(0day) gid=1003(0day) groups=1003(0day)

In the thread someone mentions that adduser won't allow that.

That aspect of adduser, at least on my system, is explicitly configurable via /etc/adduser.conf .

I don't think systemd (which is after all attempting to be universally deployed) is entitled to assume that the system administrator hasn't changed the default.

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.

"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.

> "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.

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.

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.

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

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.

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

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.

It's definitely not a safe fallback. It could be just rejected instead.

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

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

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

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.

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.)

Let’s assume you create a user account for "0pointer" → http://0pointer.net/imprint

If you can’t see the irony of granting the services of that user root access, have a look at the imprint (the owner of that domain).

bug was closed, because not a problem.

Reply on news.ycombinator.com