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.