Mike Leibowitz was recently in the pam stack for ssh logins. Mike, do you have any suggestions?
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Karol Lewandowski > Sent: Tuesday, March 11, 2014 1:35 PM > To: Kok, Auke-jan H; Yin, Kangkai > Cc: [email protected] > Subject: Re: [Dev] systemd user session in Tizen 3.0 mobile > > 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
