Thanks! ... we also don't have permission give +2 to util-linux. I will wait with submitting these till everything gets merged.
On 03/12/2014 11:39 PM, Kok, Auke-jan H wrote: > +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 > -- Karol Lewandowski, Samsung R&D Institute Poland _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
