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 [email protected] 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
