[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sudo-users
Subject:    Re: [sudo-users] disabling sudo fork-ing
From:       "Ciprian Dorin, Craciun" <ciprian.craciun () gmail ! com>
Date:       2010-08-20 15:23:16
Message-ID: AANLkTimyOuhzgphuFJ2+8dR_Pp6QU3K3uNLqazuPa13D () mail ! gmail ! com
[Download RAW message or body]

On Fri, Aug 20, 2010 at 18:04, Todd C. Miller <Todd.Miller@courtesan.com> wrote:
> In message <AANLkTi=t7Vd8MjdSwXaEWuhKGnVVwrVON9f8DBm+iENu@mail.gmail.com>
>            so spake "Ciprian Dorin, Craciun" (ciprian.craciun):
>
>>       Couldn't there also be a command line argument that forces this
>> disabling? (Because I doubt that the upstream ArchLinux maintainer
>> would accept the `--disable-pam-session` in the official builds...)
>
> Not without breaking the PAM session support.   Something needs to
> wait around to close the session after the command exits.   In the
> past sudo would open the session and immediately close it but this
> caused problems for some PAM modules.
>
> I'd much rather get to the bottom of whatever the actual signal
> issue is with running daemons via sudo using runit or daemontools.

    For my current usage `sudo` relays all the needed signals. (But if
you check the man page you'll see that `runit` specifies some "control
modes" that trigger other kinds of signals (ALRM, QUIT, USR1, USR2,
STOP and CONT (of which STOP can't be caught by a process just like
KILL)).
        http://smarden.org/runit/runsv.8.html

    For `daemontools` (which was the inspiration for `runit` and which
is more widely deployed) it's almost the same (STOP, CONT, QUIT).
        http://cr.yp.to/daemontools/svc.html

    I also suppose that `sudo` is used in a lot of scripts which
aren't intended directly for users (e.g. control scripts). Thus this
change (of forking and waiting) might have other hidden impacts.

>   - todd

    Thanks,
    Ciprian.

[prev in list] [next in list] [prev in thread] [next in thread]