[systemd-devel] The whole su/pkexec session debate

[Colin Guthrie]

Hi!

'Twas brillig, and Colin Walters at 20/11/13 14:49 did gyre and gimble:
> On Wed, 2013-11-20 at 10:16 +0000, Colin Guthrie wrote:
> 
>> How do we fix this?
> 
> There are a lot of cases - "screen" is just one of them.  I think to
> make forward progress on this we'll have to enumerate the cases,
> evaluate the problems with each, then for each problem, evaluate a fix -
> and make sure that fix doesn't regress one of the other cases.  Fun! =)

Yup!

> One very important thing that's in the mix here is the user at .service
> future.  It helps us move forcefully away from the old model of
> independent sessions, a direction we've been going incrementally via
> additions of things like XDG_RUNTIME_DIR (and then higher level things
> on top like a per-user bus instead of per-session).

ACK again.

> Cron for example could be spawned from user at service.
> 
>> But in the case of screen I'm specifically asking for a new, stand alone
>> session.
> 
> I'd agree; but the fix would be fairly invasive for screen.  I think
> it'd have to become setuid root, so it could request a new session.

Yeah that was my fear too.

Although perhaps this is just something that can be done via policy -
e.g. perhaps screen can just ask logind to create a new session for us
and then running some specific shell therein (i.e. a
screen@$newsid.service) then immediately attaching to it.

Perhaps this just needs something to control whether or not it's allowed
to ask logind for a shell. This can perhaps be something controlled by
system policy - e.g. you may be allowed but have to enter your password
again, or you may just be allowed without further auth.

I think eventually the semantics could be quite nice and could
potentially avoid the need for setuid but I don't really know the extent
of the needed infra here.

>> Perhaps this is all OK, and the "closing" state here is not a problem.
>> But such apps and use cases really are not compatible at all with the
>> kill-session-processes= option of pam_systemd and it would be nice to do
>> things properly.
> 
> I believe that option is not the default precisely because of screen.

Makes sense.

> But anyways...we have to take some level of incrementalism here.
> Martin's patch is a very small and correct fix for a real-world problem.
> My patch is a bit more invasive, but I think it's going closer to the
> root of the problem.

Absolutely. It is just nice to get an overview of the "bigger picture"
here. Perhaps someone can start to write up a "future of sessions" wiki
page with a few notes on what is needed going forward.

Cheers

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/