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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
