Hi, I agree that suggestion is enough for sdb/ssh but there is also /bin/login.
The problem is that 'login' pam config is being used by both /bin/login (for serial logins) and user-session-launcher (for graphical ones). https://review.tizen.org/git/?p=platform/upstream/user-session-units.git;a=blob;f=src/pam.c;h=4d5213328f8d041e308297f9ac832a9361957bf9;hb=cf41c1d59c7eb449c0401b4bf356aa1f8f2a6ca1#l93 Thus, I think we need to (re)introduce custom pam config for user-session-launcher with pam_systemd.so enabled and disable it everywhere else. Cheers, -- Karol Lewandowski, Samsung R&D Institute Poland On 03/12/2014 07:23 AM, Kok, Auke-jan H wrote: > hey, > > The suggestion was to make pam_systemd.so not used for ssh or sdb > logins, currently the ssh pam file inherits pam_systemd.so from > system-auth (I think) and that's how it gets started - it would be as > trivial as removing the inheritance ("session include system-auth") > and replacing it with the session lines from /etc/pam.d/system-auth > for "session" but sans pam_systemd.so > > hth > > > On Tue, Mar 11, 2014 at 1:35 PM, Karol Lewandowski > <[email protected]> wrote: >> Folks, >> >> Sorry to revisit such an old thread, but issues raised there >> seem to still apply to most recent images (both ivi and mobile). >> >> The problem is that logging in via serial-console (ssh/sdb) >> causes whole user session to start - this includes X11 server >> on mobile and wayland on ivi. >> >> I have briefly looked into logind-exported stuff (/run/systemd/ >> {seat,session}) hoping that something could be used to decide if >> GUI stuff should be started or not. Seats export CAN_GRAPHICAL >> variable. In our case we always have one seat ("seat0") and >> CAN_GRAPHICAL is always set ("=1"). My understanding is that >> each physical serial line would be distinct seat (with >> CAN_GRAPHICAL=0). Network lines would be handled differently. >> >> Anyway, fixing this correctly requires considerable amount of time >> I don't currently have. >> >> Kai proposed moving pam_systemd to PAM config used by >> user-session-launch only which seems sensible workaround. >> >> Could you give us hint how this should be solved? Is using >> Kai's workaround ok still with you? >> >> Cheers, >> -- >> Karol Lewandowski, Samsung R&D Institute Poland >> >> On 01/07/2014 07:18 PM, Kok, Auke-jan H wrote: >>> On Tue, Jan 7, 2014 at 2:14 AM, Yin Kangkai <[email protected]> wrote: >>>> On 2014-01-06, 11:06 -0800, Patrick McCarty wrote: >>>>> 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 isn't such a bad idea - at least temporarily... >>> >>>> 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. >>> >>> makes it harder to work with `systemctl --user`, so that's a downside again. >>> >>>>> 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. >>> >>> either run them as root, or run them as User=pulse (for example). But >>> never as User=app... >>> >>>>> 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... >>> >>> ln -sf some.target ~/.config/systemd/user/default.target >>> >>> been possible since systemd-40 or so... :^) >>> >>> Auke >>> >>>> >>>> Regards, >>>> Kangkai >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> https://lists.tizen.org/listinfo/dev >>> >> >> > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
