4 ms·

> 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

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

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