[Dev] systemd user session in Tizen 3.0 mobile

Kok, Auke-jan H auke-jan.h.kok at intel.com
Wed Mar 12 06:23:21 GMT 2014


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
<k.lewandowsk at samsung.com> 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 <kangkai.yin at intel.com> 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
>> Dev at lists.tizen.org
>> https://lists.tizen.org/listinfo/dev
>>
>
>


More information about the Dev mailing list