[systemd-devel] [PATCH] Create a new logind session from a systemd --user unitt

[Abdó Roig-Maranges]

Hi,

Thanks a lot for your explanations!


> Either use a display manager or simply "update" your existing session's
> tty to graphical temporarily, rather then placing things on a new
> tty. (Note that the Fedora startx script does this implicitly this way)

I figured I could use a systemd unit as a sort of very thin display manager to
create a second session for my own user. I'll try using the same tty, without
extra sessions, then.


> We are working on this bit by bit. If you want this to go faster, then
> please work with us, and write patches for libX11 and D-Bus.

Well, this is just for my home PC... I tried managing user daemons, X, etc. via
systemd --user some time ago, and loved it! I'm just trying to do it in a way
that will not break much as the thing evolves.


>> I think initgroups in core/execute.c always needs privileges. It is always
>> called when User=blah is set on a service file and always fails on systemd user
>> instances for unprivileged users. This prevents from using PAM within a systemd
>> user instance, for example.
>
> Not following here. initgroups() is called before dropping prvis, so it
> should always work. Can you elaborate?

I was referring to the systemd --user instance running as user abdo via the
user at .service unit. Then when I started a systemd --user unit containing

  User=abdo
  PAMName=login

I got the GROUP error I reported. In this case the initgroups() is called as my
unprivileged user abdo because it is the user for which the systemd --user
process is running. Did I miss something? I didn't look at it very carefully,
just guessed the problem and tested a solultion that happened to work.

I understand I shouldn't do the PAM stuff from a systemd --user unit, but the
problem with group privs I encountered in systemd --user instances may still be
an issue.

Abdó Roig.