On Thu, 23.10.14 13:47, Damien Robert (damien.olivier.rob...@gmail.com) wrote:
> >From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) : > > On Thu, 23.10.14 08:09, Damien Robert > > (damien.olivier.robert+gm...@gmail.com) wrote: > > > But isn't using default.target more flexible than basic.target? When > > > basic.target is activated I expect at least socket.target, timers.target > > > and path.target to get activated too; whereas I could imagine an user > > > wanting a completly empty user session [*], which could be done with an > > > empty > > > default.target [#]. > > > basic.target includes sockets.target, busnames.target, timers.target > > and paths.target as well as sysinit.target. > > No, that's the system wide basic.target. The user basic.target only has > sockets, timers and paths. Oh indeed, there is not sysinit.target. It sounded so wron in a user context... I figure if people want to stick something in there they can just as well use basic.target here... > But I was arguing that basic.target has a well defined meaning (basic > system wide/user wide system initialisation), and we may want to allow > default.target (in a user session) to be different from basic.target, even > if they should be the same for most user cases. sure, that sounds like something to support. i'd still say though that pam_systemd should only wait for basic.target, since that's where all the "listening" bits should be established, and everything else can be started later. > > Yes, all user code really should go through PAM, so that security > > labels and resource limits can be set up properly. > > Yeah but do they need to go through pam_systemd.so also? Yes. All user code should go through pam_systemd.so too, so that it gets moved into the user's slice. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
