[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

configurable service name advice wanted

Could I get some advice frome from the list?

I'm working on finishing touches to
PAM support in kde.
(kdm, kscreensaver: xdm and xlock workalikes)

It appears that however xdm is configured for PAM,
that will be appropriate for kde.

So kdm is using  the service name "xdm" as the default.
Presumably 99% of PAM-aware systems that kde  
is installed on will have PAM support configured for
xdm in /etc/pam.d/xdm or whereever.

This way the installer will not necessarily need root
access to configure a pam service.  (assumes the
installer may be allowed to compile and run stuff without
being root (the screenlock part, at least, but not kdm of course)

Also a PC user with RedHat installed who isn't
even aware they have a PAM system can install from
an rpm and have a drop-in replacemenet for xdm
that will function "identically" (but see footnote *)

To handle any other cases, I'm contemplating
allowing an automake option
--with-pam=foo  (to compile in service name "foo"
instead of the default "xdm")
for example.    

Another possibility is to configure the service name in a
root-access-only configuration file.

Are these ideas awful security holes?
Only root will be able to run kdm.
A user could run kde with
startx and not use kdm:
the only PAM access in that case is the display
lock password query.

Duncan Haldane

PS:  The broken PAM support in kdm with
RedHat5.0 that works in RH5.1 
turned out not to be anything to do
with PAM-0.64 vs. PAM-0.59, or glibc updates.

The code compiled with egcs works perfectly
on both RH5.1 and 5.0.   Its the code
compiled with gcc, gcc-c++ that has PAM problems.


(One difference: kdm can 
call session support in session.c: 
which isn't done in RH's xdm
so far, though.  

Someobody requested this
so they could PAM-configure some filesystems  to be mounted
and unmounted when the session is opened and closed;
In RH5.x xdm, the pam handle is closed immediately
after successful authentication, before the
session starts: there is a crytic RH comment
about not implementing session support yet
because of "not knowing yet how to tear the session down",
(or words to that effect)
before closing the pam handle - does anyone know about
the reasons for this?)

E-Mail: Duncan  Haldane <f.d.m.haldane@MCI2000.com>
Date: 09-Jun-98
Time: 16:13:50

This message was sent by XFMail

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []