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

Re: chrooted accounts

Jim Dennis wrote:
> 	There is a different SysV login convention for user-specific
> 	chroot -- where the *shell* field is specified as "*"
> 	This is supposed to be standard (for SVR4 systems?) and is 
> 	documented in Garfinkel and Spafford's _Practical_Unix_and_
> 	Internet_Security_ (O'Reilly & Associates, pp 232-234).  
> 	Here's how it's supposed to work:
> 		You create the passwd entry like so:
> 	jailbird:x:1234:98:John JailBird:/special/jail:*
> 		When John JailBird logs in and correctly enters 
> 		his password the login program does a chroot() to
> 		the /special/jail (in this example) and execs a 
> 		new login (which can authenticate him again).

If I understand this correctly, after (possibly) authenticating the user,
the first login program makes no effort to log the user in (change uid.. or
the terminal ownership..) it simply does an exec() after a chroot().

The way we have opted to implement login within PAM is by "fork()"ing the
user's shell, so the natural extension of this is to "fork()" the user's
chroot()-ed secondary login.  However, vhangup(), is going to cause trouble
when it finds both processes on the same terminal line.  I guess we can
protect against this by blocking SIGHUPs (much as login does now when it
does the vhangup).

I'm thinking of implementing this scheme.  Would you have any objections to
me extending the use of * in the shell field to, */bin/bash in the case that
I am happy for the user to jump straight into 'bash' in the /special/jail
cell?  I guess this will be a little tricky getting the chroot() positioned
correctly, but I would like to make it possible for the user to login to an
environment containing no authentication information.


               Linux-PAM, libpwdb, Orange-Linux and Linux-GSS

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