On Thu, 8 Sep 2016 23:46:46 +0200
Markus Teich <markus.teich_AT_stusta.mhn.de> wrote:
Good morning,
> I think its not much of a complexity to specify the group as well and
> also is more explicit than implicitly using the users default group
> (which might have some surprises).
>
> > Again I'm not really against that, just asking for some opinions.
> > I've got yours!
>
> I don't have a clear opinion on the nogroup vs. nobody matter, but
> since it is just a default and can easily be changed I just merged
> the patch for now (I hope I got the correct version). If somebody[0]
> gives a good argument, we'll just change the default.
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 contribution, FRIGN.
I was happy to do it!
Cheers
FRIGN
--
FRIGN <dev_AT_frign.de>
Received on Fri Sep 09 2016 - 08:32:05 CEST