Re: [hackers] [slock] [PATCH] Properly drop privileges

From: Quentin Rameau <>
Date: Fri, 9 Sep 2016 09:17:48 +0200

> it is always recommended to read the motivation for doas and why sudo
> was invented in the first place. I wrote this patch under two
> assumptions
> - in most cases, the slock post-lock-cmd wouldn't need
> permissions
> - if it needs permissions, we can't just not drop privileges.
> Instead, it should be simple to just create a group "slock"
> or something and specify there what it is allowed to do.
> As an example, let's say I want to run a privileged command "rootsjob"
> after locking.
> The first thing I do is create a group "slock" and enter it in
> config.h. We cannot have a -u or -g flag for slock to set the dropuser
> because that would allow impersonation of anybody. We are protected by
> having it a compiled-in option because suid-applications cannot be
> modified without losing the suid-bit.
> user = "nobody"
> group = "slock"
> Now I edit my sudoers/doas.conf file and do the permission control
> there. Especially doas is really simple to set up and can allow
> fine-grained permission control. For doas.conf it would be
> permit nopass :slock cmd rootsjob
> and it can be extended from there on. slock can now be executed with
> slock doas rootsjob
> and we fixed the permission problem. The reason why doas/sudo exists
> is really because the duality root/non-root is too strict in many
> cases. The midway cannot be solved by us, but we need to put trust
> into the facilities provided by the system and allow the users to be
> flexible (for instance, one could also create a slock user, so it
> would be bad to implicitly set the groups from the user and vice
> versa).
Thanks for the usual fifty lines lecture about the basis.

I don't think that is related to the choice of the “nogroup” group,
but instead of giving back what we told you on IRC, maybe you could
append it in the README for future users who don't know about execution
privilege escalation programs, where it'd me more useful!
Received on Fri Sep 09 2016 - 09:17:48 CEST

This archive was generated by hypermail 2.3.0 : Fri Sep 09 2016 - 09:24:16 CEST