PAM exec patch to allow PAM_AUTHTOK to be exported.

[Dan Lukes]

Zane C.B. napsal/wrote, On 05/21/07 04:33:
>> In advance, you need
>> catch not only pam_sm_session_open but pam_sm_session_close (i
>> assume you plan to umount resource also). Unfortunately (unless I
>> miss something) pam_exec has no way to pass about 'direction' to
>> called program. You can't use simple heuristic "when not mounted
>> mount it and vice versa" also because the same user can have more
>> than one simultaneous active session.
> 
> True. That would be another issue. Regardless, it is going to need a
> daemon to run in the background or something. 

	In the fact, you are in trouble because the OS doesn't know "user 
session" so it didn't help you to maintain the information. User session 
is PAM category.

	You are true - you need a system-wide persistent object that hold 
information "a session for user X remain active". You can create a 
daemon, you can create a file in the filesystem or so. But it's not 
solution of your main problem - where to catch information the session 
start/ends.

	At the first, you have with session start whenever PAM not used for 
authentication. It's not only telnetd which doesn't use PAM at all. 
There are many daemons that can start user-scripts but not as part of 
(PAM) user session. For example CRON, SENDMAIL (when "| script.sh" used 
in .forward) and so on.

	Even worse is catching of session-end. At the first, it's application 
responsibility to call PAM's session close and the close may not be 
called in some cases of abnormal end. Even if we ignore those abnormal 
cases, regular exit of the application authenticating the user into 
system constitute end of PAM's session, but it doesn't mean that no user 
proces is running in the system. There are may be tenths of proceses 
started during session that run in the background, detached from 
terminal and owned by INIT as parent process.

	To make things more complicated, a process can have more than one 
effective user during lifetime. If euid chages - are you ready to remap 
directories accordingly ?

> I don't think using PAM to figure out if it should be unmounted is a good idea

	In the fact, I don't thing the PAM is good place to figure out the 
directory needs to be mounted as well.

	PAM may be the place where you can stealth the user name and password 
an store it somewhere for later use.

	You can create kernel module monitoring process creation and EUID 
changes. It can map/unmap user's directories.

	Unfortunately, you need secure persistent storage of every user name 
and password (user processes may be started shortly after the start of 
system - before the user log-in first time, so in-memory only storage is 
not sufficient).

	By the way, we still speak about "name+password" authentication only. 
Your system can't work when user authenticate itself by other system 
(digital signature, OTP, challenge-response, magnetic or chip card, a 
biometric based authentication and so on).

	If your system allow access via ssh and a user will use authentication 
wia key, then you have no way to do what you want automagicaly.

	Even if we forget other authentication system than "name+pwd", 
persistent password database is security risk. Persistent storage of 
user credentials without it's approval may have law consequences also.

	If we speak about proprietary solutions (for your only) it may not be 
problem. If we speak about "standard distribution solution" we can't 
forged about it.

> unless you kill all processes owned by that user upon session close.

	Insufficient. Process with effective rights as a user can be started 
later, not as a part of a session. You need global knowledge about all 
processes and their efective UIDs.

> IMO it
> would be best to check if there are any processes running owned by
> that user before unmounting it and if there are, leave it for the
> cleanup daemon.

	"Cleanup daemon" is "end-session" solution. Not "start-session". You 
need kernel module for "is a process runing for a user" tracking. PAM 
may help with creating persistent system password database used by this 
module for real mounting.

	Or you can reevaluate what you want. If you need "automagic mouting" 
avaiable during interactive user sessions only then things become simpler.

> Yup. Moving to hackers. :)

	I'm not a member.

					Dan



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