+2'd these, except the util-linux (apparently I can't +2 this... strange) Auke
On Wed, Mar 12, 2014 at 10:53 AM, Karol Lewandowski <[email protected]> wrote: > 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
