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

Reply via email to