On 02/03/2014 03:28 PM, David C. Rankin wrote:
> On 02/03/2014 02:58 PM, David C. Rankin wrote:
>> On 02/03/2014 02:41 PM, Slávek Banko wrote:
>>> Outside of that was found in tdebase, XDG_SESSION_COOKIE is used in kpowersave 
>>> and tdepowersave (will be fixed after commit patch from bug 1597). This is 
>>> good news - on the ConsoleKit no more dependent - only TDM. In other words, 
>>> it should be enough to add support for SystemD session into TDM. I will try 
>>> to assess how difficult this task is...
>>>
>>> Slavek
>>
>> That is good news! Also, at least for tdebase, the preprocessor checks already
>> exclude the console kit code when not defined. Checking the running processes,
>> it looks like everything required from Arch is already started and running:
>>
>> /sbin/init
>> /usr/lib/systemd/systemd-journald
>> /usr/lib/systemd/systemd-udevd
>> /usr/lib/systemd/systemd-logind
>> /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile
>> --systemd-activation
>> /sbin/agetty --noclear tty1
>> /opt/trinity/bin/tdm
>>  \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla
>>  \_ -:0
>>      \_ /bin/sh /opt/trinity/bin/starttde
>>          \_ /opt/trinity/bin/tdeinit_phase1
>>              \_ kwrapper ksmserver --windowmanager twin
>> /usr/bin/gpg-agent --daemon
>> /usr/bin/ssh-agent -s
>> dcopserver [tdeinit] --nosid --suicide
>> kded [tdeinit] --new-startup
>> start_tdeinit --new-startup +kcminit_startup
>>
>> All we need is to provide is the minimum porting requirements:
>>
>> Minimal porting (without multi-seat) requires the following:
>>
>> 1. Remove/disable all code responsible for registering your service with ConsoleKit.
>> 2. Make sure to register your greeter session via the PAM session stack, and
>> make sure the PAM session modules include pam_systemd. Also, make sure to set
>> the session class to "greeter." This may be done by setting the environment
>> variable XDG_SESSION_CLASS to "greeter" with pam_misc_setenv() or setting the
>> "class=greeter" option in the pam_systemd module, in order to allow applications
>> to filter out greeter sessions from normal login sessions.
>> 3. Make sure to register your logged in session via the PAM session stack as
>> well, also including pam_systemd in it.
>> 4. Optionally, use pam_misc_setenv() to set the environment variables XDG_SEAT
>> and XDG_VTNR. The former should contain "seat0", the latter the VT number your
>> session runs on. pam_systemd can determine these values automatically but it's
>> nice to pass these variables anyway. In summary: porting a display manager from
>> ConsoleKit to systemd primarily means removing code, not necessarily adding any
>> new code. Here, a cheers to simplicity!
>>
>> It looks like #2 is where the work is. Coding wizard like you - no sweat..
>>
> 
>   I don't know if this helps or not, but I noticed that mkpamserv installed as
> part of tdebase and used in the tdebase.install script creates a trinity pam
> file with:
> 
> #%PAM-1.0
> 
> #auth       required     pam_securetty.so
> auth       requisite    pam_nologin.so
> auth       include      system-local-login
> account    include      system-local-login
> session    include      system-local-login
> 
>   The inclusion of system-local-login, include the following:
> 
> cat ../pam.d/system-local-login
> #%PAM-1.0
> 
> auth      include   system-login
> account   include   system-login
> password  include   system-login
> session   include   system-login
> 
>   Which in-turn includes 'system-login' for each auth, account, password and
> session:
> 
> cat ../pam.d/system-login
> #%PAM-1.0
> 
> auth       required   pam_tally.so         onerr=succeed file=/var/log/faillog
> auth       required   pam_shells.so
> auth       requisite  pam_nologin.so
> auth       include    system-auth
> 
> account    required   pam_access.so
> account    required   pam_nologin.so
> account    include    system-auth
> 
> password   include    system-auth
> 
> session    optional   pam_loginuid.so
> session    include    system-auth
> session    optional   pam_motd.so          motd=/etc/motd
> session    optional   pam_mail.so          dir=/var/spool/mail standard quiet
> -session   optional   pam_systemd.so
> session    required   pam_env.so
> 
>   I don't know if this is common, but that shows what pam modules are
> available/called on arch to allow logind/dbus/polit to track and manage user
> sessions and device access on arch -- if it makes any difference.
> 

Per the suggestion on the freedesktop page, perhaps adding something like the
following around line 1320 of client.c would make explicit the needed environment:

	if ((pretc = pam_misc_setenv( pamh, XDG_SESSION_CLASS, "greeter", 0 )) !=
PAM_SUCCESS) {
		ReInitErrorLog();
		LogError( "pam_misc_setenv() for %s failed: %s\n",
		          curuser, pam_strerror( pamh, pretc ) );
		return 0;
	}
	if ((pretc = pam_misc_setenv( pamh, XDG_SEAT, "seat0", 0 )) != PAM_SUCCESS) {
		ReInitErrorLog();
		LogError( "pam_misc_setenv() for %s failed: %s\n",
		          curuser, pam_strerror( pamh, pretc ) );
		return 0;
	}
	if ((pretc = pam_misc_setenv( pamh, XDG_VTNR, "7", 0 )) != PAM_SUCCESS) {
		ReInitErrorLog();
		LogError( "pam_misc_setenv() for %s failed: %s\n",
		          curuser, pam_strerror( pamh, pretc ) );
		return 0;
	}

** check syntax, this is my guess at it or we could use something like:

pam_putenv(pamh, "XDG_SESSION_CLASS=greeter");

instead of pam_misc_setenv. Other than that, the other area where I don't fully
understand what is needed is in #3 - "Make sure to register your logged in
session via the PAM session stack as well, also including pam_systemd in it."
That may already be done, but I would like to understand a bit better how/where
logged in user registration takes place and what it means to include pam_systemd
in it?

-- 
David C. Rankin, J.D.,P.E.