[scponly] Re: Patch: passwd compatibility in chroots

Kaleb Pederson kpederson at mail.ewu.edu
Thu Mar 9 18:34:41 EST 2006


You will need both.  I hadn't thought about making the two options mutually 
exclusive and handling both cases in my patch -- perhaps that's better, but 
I'm not sure.

I didn't want to prevent people from using the current functionality.  It's 
possible that some people won't need the ability to change the password 
outside of a chroot, as their auth mechanism might be external, in which case 
it's better if they are chrooted.

The patch will not change how the chroot gets built, although perhaps it 
should?  The password binary does not need to be within the chroot.  The way 
the patch works, before the user would have been chrooted, the normal passwd 
program is used to change the password and the connection is closed.  This is 
what allows the password file(s) outside of the chroot to be changed.

Would it be better if the flags were mutually exclusive?  I don't think we 
should disable the prior functionality?  Perhaps the flag just needs to be 
renamed to be more representative of what's happening.

Note. I did setup configure to output some additional information if only my 
flag is used:

$ ./configure --enable-chrooted-passwd-compat
...
configure: not enabling chrooted passwd compatibility, --enable-passwd-compat 
required
configure: not enabling chrooted passwd compatibility, 
--enable-chrooted-binary required
...

Suggestions on how to make this more clear? It seems like it needs to be 
better documented, but I don't really see a place for it -- a new section in 
README?

Thanks.

--Kaleb

On Thursday 09 March 2006 3:22 pm, Ensel Sharon wrote:
> Kaleb,
>
> On Thu, 9 Mar 2006, Kaleb Pederson wrote:
> > At the request of a couple of people, I'm resubmitting an updated patch
> > for the ability to change passwords when using a chroot.
> >
> > Typically, if the passwd program is executed in a chroot, it will, at
> > best, change the password and shadow files that exist within the chroot. 
> > This, however, is generally not sufficient to enable the user to log into
> > the system with the password that they now expect to be set, as the
> > shadow file is outside of the chroot (note, this might not apply to other
> > auth mechanisms).
> >
> > The attached patch (against CVS HEAD) does the following when
> > --enable-chrooted-passwd-compat is enabled:
>
> Thank you so much - I really needed this and appreciate it a lot.
>
> A quick question - do I need _both_ flags:
>
> --enable-passwd-compat
> --enable-chrooted-passwd-compat
>
> Or can I just use the second one which performs the functions of both ?  I
> ask because after configuinr with _only_ your flag, I noticed that the
> passwd binary did not get placed into my new jail ...
>
> Thanks again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : https://lists.ccs.neu.edu/pipermail/scponly/attachments/20060309/1e0b7477/attachment.bin


More information about the scponly mailing list