bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A deferred authorization-granting translator


From: Olaf Buddenhagen
Subject: Re: A deferred authorization-granting translator
Date: Tue, 4 Jan 2022 12:40:01 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

Hi,

On Wed, Dec 29, 2021 at 12:56:23PM +0100, Dr. Arne Babenhauserheide wrote:

>     echo HELLOWORLD > /hello && \
>     settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) 
> --groupname=user

The `-c` is redundant: you know the node already exists, as you just
wrote to it...

(Also, since you probably assumed that there is no pre-existing
translator when writing, arguably the `-g` is redundant as well...)

> It also starts a daemon that will remove the group again after 5
> minutes (modelled after the temporary permissions to run privileged
> without password granted by sudo).

That's not terribly useful: the program might have exec'ed or forked in
the mean time, or otherwise handed off the authority...

To have an enforceable timeout, you'd probably need some sort of custom
auth token with a bilt-in self-destruct, or something along these
lines... (Haven't thought about it much, though.)

More generally, my intuition is that the `auth` mechanism should be at
the heart of this: the whole "find PID and check its groups" approach
doesn't feel quite right... Though frankly, I can't really say much
beyond that right now.

> Accesses from two different translators can currently race for the
> reply. To fix this, the translator should write the PID and a random
> LABEL into the request. The program should repeat that label for
> replies to ensure that the reply and request can be matched. If
> receiving a non-matching reply, it MUST be written into the grant
> again after a random delay to enable a matching translator to
> retrieve the grant.
> REQUEST: PID LABEL
> GRANT: RET LABEL (RET=0 is success)
> LABEL=$RANDOM
>
> The system assumes having a single permission granting program per
> user. For a setup with multiple unconnected sessions per user (like
> several TTYs) the permission granting program needs to coordinate
> between these.

I'm pretty sure there must be a more Hurdish (and robust) way of
handling this communication... But again, haven't thought much about it.

Either way, it's good that you are looking into this: it's bringing up
interesting questions :-)

-antrik-



reply via email to

[Prev in Thread] Current Thread [Next in Thread]