Patches here: user-session-units:
https://review.tizen.org/gerrit/17938 https://review.tizen.org/gerrit/17939 util-linux (system-auth): https://review.tizen.org/gerrit/17937 On 03/12/2014 04:53 PM, Karol Lewandowski wrote: > 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 >>>> >>> >>> >> >>> >> >> > > -- Karol Lewandowski, Samsung R&D Institute Poland _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
