Date: Mon, 21 May 2007 13:53:41 +0200 From: Dan Lukes <dan@obluda.cz> To: "Zane C.B." <v.velox@vvelox.net> Cc: freebsd-hackers@freebsd.org Subject: Re: PAM exec patch to allow PAM_AUTHTOK to be exported. Message-ID: <46518845.1000406@obluda.cz> In-Reply-To: <20070520223338.49409574@vixen42> References: <20070519130533.722e8b57@vixen42> <86bqgfh4w0.fsf@dwp.des.no> <20070520120142.39e86eae@vixen42> <86tzu7ifp2.fsf@dwp.des.no> <20070520132410.58989605@vixen42> <4650939B.6020004@obluda.cz> <20070520200310.4a79954e@vixen42> <4650F93A.3080603@obluda.cz> <20070520223338.49409574@vixen42>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46518845.1000406>