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