Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 63 posts

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

#41

Post by srett »

hahainternet wrote: post #17
srett wrote: post #10

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 *" sho…

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?

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.

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

#42

Post by mjw1007 »

lysium wrote: post #15
haik90 wrote: post #9

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.

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

#43

Post by ArneBab »

mjw1007 wrote: post #35
zokier wrote: post #16

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.

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.

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

#44

Post by JdeBP »

viraptor wrote: post #33
hahainternet wrote: post #22

Earlier quoted context omitted.

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

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…

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.

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

#45

Post by srett »

mjw1007 wrote: post #39
srett wrote: post #10

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 *" sho…

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 wr…

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.

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

#46

Post by ArneBab »

codefined wrote: post #28
darklajid wrote: post #23

Earlier quoted context omitted.

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.

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

#47

Post by ArneBab »

viraptor wrote: post #33
hahainternet wrote: post #22

Earlier quoted context omitted.

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

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

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

#49

Post by JdeBP »

codefined wrote: post #28
darklajid wrote: post #23

Earlier quoted context omitted.

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.

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.

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

#50

Post by ArneBab »

ArneBab wrote: post #48

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.
Post reply on HN