6 ms·

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

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?

detaro 9y ago
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")
- hahainternet 9y ago
  > 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?
  - detaro 9y ago
    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!
  - viraptor 9y ago
    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?
    - JdeBP 9y ago
      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://jdebp.eu./Softwares/nosh/guide/setuidgid.html * http://cr.yp.to/daemontools/setuidgid.html http://cr.yp.to/daemontools/setuidgid.html * http://untroubled.org/daemontools-encore/setuidgid.8.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.
    - ArneBab 9y ago
      Or maybe 0pointer → http://0pointer.net/imprint http://0pointer.net/imprint
      - digi_owl 9y ago
        He seems to prefer various alcoholic drinks when posting not posting under his own name though...
- darklajid 9y ago
  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).
  - codefined 9y ago
    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.
    - ArneBab 9y ago
      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.
    - JdeBP 9y ago
      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.
mjw1007 9y ago
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.
srett 9y ago
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.

detaro 9y ago

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

hahainternet 9y ago
> 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?
- detaro 9y ago
  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!
- viraptor 9y ago
  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?
  - JdeBP 9y ago
    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://jdebp.eu./Softwares/nosh/guide/setuidgid.html * http://cr.yp.to/daemontools/setuidgid.html http://cr.yp.to/daemontools/setuidgid.html * http://untroubled.org/daemontools-encore/setuidgid.8.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.
  - ArneBab 9y ago
    Or maybe 0pointer → http://0pointer.net/imprint http://0pointer.net/imprint
    - digi_owl 9y ago
      He seems to prefer various alcoholic drinks when posting not posting under his own name though...
darklajid 9y ago
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).
- codefined 9y ago
  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.
  - ArneBab 9y ago
    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.
  - JdeBP 9y ago
    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.

mjw1007 9y ago

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.

srett 9y ago

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.