3 Feb
2014
3 Feb
'14
5:15 p.m.
On Monday 03 of February 2014 22:59:39 David C. Rankin wrote:
On 02/03/2014 03:28 PM, David C. Rankin wrote:
Now I read it again and if I understand it correctly, is that about correct
setting PAM => no need to change the source code of TDM?
Slavek
--
On 02/03/2014 02:58 PM, David C. Rankin wrote:
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? On 02/03/2014 02:41 PM, Slávek Banko wrote:
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. 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..