[Xlock-develop] [Fwd: Re: [Xlock-discuss] PAM integration]

[Dan Lukes]

	Well, I see the new list has been created and I has been subscribed 
into it automatically. Well, no problem. I'm resending the last email 
from thread originally started on Xlock-discuss list.

	I don't want to push anybody to anything, I only remember the recent 
email with no response to it. In advance, I have no spare time to create 
offered patch now. But before we can think about creating the patch, 
there must be consensus it's not broken idea at all, so when you have 
spare time and nothing to do, recall the included email, read it and 
create own opinion about the ideas described within.

					Dan


-------- Original Message --------
Subject: Re: [Xlock-discuss] PAM integration
Date: Mon, 11 Sep 2006 01:59:25 +0200
From: Dan Lukes <dan at obluda.cz>
To: xlock-discuss at tux.org
References: <44EA61D9.9050902 at obluda.cz> 
<20060822121023.d8c569d3.jay-dev at simcom.ru>

Yuri Bushmelev napsal/wrote, On 08/22/06 10:10:
>> 	So I'm arriving to conclusion the fully integrated PAM authentication 
>> must be driven by PAM layer completely with no pre-PAM questions.
>> 
>> 	Any objection ?
> 
> Please check docs/TODO file in xlockmore distribution archive also. This file
> contains some things about authentication in general.

	I read it. There seems to be only chapter 3 related to PAM/password.
Unfortunately, most of the ideas is based on (IMHO) broken concept
"password obtained outside of PAM". Its problem of checkpasswd-pam which
is recommended as a reference also.

	As i mentioned before, PAM has no concept of "now asking for username;
now asking for password". It can send two types messages to user (error
and information) and ask two types of question - with and without echo.

	PAM is modular system. Nobody can know the conversation flow
implemented by an unknown module.

	You can't assume that conversation will contain one and only one "no
echo" question containing magic word "password". You can make no safe
assumptions about conversation - it is broken idea.

	Well - you can offer and "pre-requested" password for modules - but not
by blind man-in-the-middle modification of PAM conversation. You should
use pam_set_item(,PAM_AUTHTOK,) method. Unfortunately, PAM modules may
or may not use the information. As you can't decide if there is a module
interested in this kind of authentication, you may abuse the user by
goot-for-nothing question. And even more - you may confuse user asking
for password, as user don't know any (as configured PAM modules need no
password from user for successfully authentication).

	Shortly - I considered any pre-PAM question as superfluous and possibly
confusing. It's incompatible with current system "central ask for
paswword" then use it in several kinds of password check systems.

>> 	Should I try to make patch ?

> Why not? :)

	Simple. My idea about the PAM integration seems to be too different
from current concept. It's also incompatible with planned "TODO" steps.

	For now, I have dirty hack which satisfy my specific needs. I don't
want to waste time preparing nice patch which will be denied because of
"ideas incompatibility".

	So I prefer to explain my ideas for now. I will try to make patch if
you (and David) will not reject it.

	Current xlock.c:getPassword() function do some preparations (priority
and some screen-related configuration steps), then ask for password,
then call passwd.c:checkPassword for verification.

	In new code - initialization will remain unchanged.

	If PAM compiled in, then it will be called. The PAM support routines
will exactly do what the PAM layer requests with no try to understand or
modify the flow. The final result of getPassword will be derived
directly from final status of PAM.

	If PAM is not compiled, then current code (with PAM part removed) will
be called.

	E.g., PAM and not-PAM authentication become two unrelated
authentication subsystem which will never act both. Alternative - if PAM
compiled in, then active subsystem will be selected by configuration
(but one subsystem only, not both).

	Later, someone else may try to suggest an new concept of cooperation
between PAM and non-PAM subsystem. For example, non-PAM subsystem may be
called after unsuccessful PAM (in all cases, or after some fail codes
only) using item PAM_AUTHTOK as password (if available). Or non-PAM may
be called first, then PAM with previously obtained password supplied as
PAM_AUTHTOK. Or some non-PAM methods will be called before PAM and some
after PAM with password transfer between subsystems...

	It shall be configurable (if implemented) and the required
configuration seems to be so complex for me. IMHO, no non-PAM subsystem
is necesarry when PAM avaiable. The PAM is flexible enought to create
almost any chain of configuration so it shall satisfy any requirements.
Well, someone else may have different opinion. Despite of it, I will not
plan to code inter-subsystem communication nor related configuration
required for it.

	So, I'm asking again - should I try to make patch ?


						Dan



-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz


-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz