On 2014-01-06, 11:06 -0800, Patrick McCarty wrote: > Also, the call to getpwuid(3) (or getpwnam(3) in the alternate case) > validates the system account and populates the passwd struct, so the > associated user name would be available to pass to PAM when opening the > session.
I understand how this works. :) my point was if you use "app", you don't have to do any parse, pass directly to PAM and it can help you do all the following checking and authentication. But anyway, I agree uid might be more convention in systemd. Thanks for the explanation. > > I think one major problem left in this user session setup is that, > > those user session services be run each time a new user session opens > > (e.g. somewhere another user "root" login). > > > > We can fiddle with PAM configurations (/etc/pam.d) to work around > > this. > > What PAM config changes would you propose? bash-4.2# diff -urN /etc/pam.d/ pam.d.new/ diff -urN /etc/pam.d/system-auth pam.d.new/system-auth --- /etc/pam.d/system-auth 2013-12-16 14:27:47.000000000 -0800 +++ pam.d.new/system-auth 2013-02-12 20:54:28.000000000 -0800 @@ -11,7 +11,6 @@ password required pam_deny.so session optional pam_keyinit.so revoke -session optional pam_systemd.so session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so diff -urN /etc/pam.d/systemd-user pam.d.new/systemd-user --- /etc/pam.d/systemd-user 2013-12-19 13:45:35.000000000 -0800 +++ pam.d.new/systemd-user 2013-02-12 20:54:59.000000000 -0800 @@ -4,5 +4,6 @@ account include system-auth session include system-auth +session optional pam_systemd.so auth required pam_deny.so password required pam_deny.so diff -urN /etc/pam.d/user-session-launcher pam.d.new/user-session-launcher --- /etc/pam.d/user-session-launcher 1969-12-31 16:00:00.000000000 -0800 +++ pam.d.new/user-session-launcher 2013-02-12 20:54:59.000000000 -0800 @@ -0,0 +1,9 @@ +#%PAM-1.0 + +# Used by systemd when launching systemd user instances. + +account include system-auth +session include system-auth +session optional pam_systemd.so +auth required pam_deny.so +password required pam_deny.so bash-4.2# /etc/pam.d/user-session-launcher is just a link/copy to /etc/pam.d/systemd-user This can make sure systemd user session launches the whole UI, but login and su don't. Downside of this change is that sessions opened by login and su are not tracked in their own session tree, they're all in system session tree. But this is acceptable I think. > If there should be only *one* instance of a service (e.g. a middleware > service), then we should move it to the system session, but it wouldn't > run as "app" in this case. Yes, they can? with specifying "User=app" in service file. > would be useful to configure the default target on a per-user basis, > possibly in /etc/systemd/logind.conf, so that we have more flexibility > in specifying per-user units to start. Yeah good idea. is that do-able with current systemd? or we have to cook the patch... Regards, Kangkai _______________________________________________ Dev mailing list Dev@lists.tizen.org https://lists.tizen.org/listinfo/dev
