chroot sftp-server [PATCH]

Andrew Bartlett abartlet at pcug.org.au
Fri May 25 07:39:36 EST 2001


Patrick Higgins wrote:
> 
> All of this should be quite possible, but I think the sftp-server is
> going to need greater configurability. I noticed the comment at the
> beginning that it should use getopt(), but in order to get that to work,
> the code which spawns it is going to need some new features...
> 
> It seems possible to put options into the sftp subsystem definition in
> your sshd_config, but they would be the same for all users. It would be
> nice to have some kind of variable syntax to express things that change
> (like home directories). Perhaps a full-blown config file for
> sftp-server would be more appropriate?
> 
> While I'm on the topic of how the subsystem is exec'ed, I'd like to ask
> why it's exec'ed with the user's shell instead of /bin/sh. This seems to
> prevent me from giving sftp access but *not* ssh. It appears to have
> been done more or less for code reuse--perhaps do_exec_*_pty() and
> do_child() should take the shell to use as an argument, so that
> session_subsystem_req() could always specify /bin/sh?

Quite the opposite.  I give my users a restricted shell, and this way I
can limit per-user use.  I simply let my taint-mode perl script accept
the -c option, compare it with the list of permitted programs (currently
just sftp-server) and run it with the appropriate option.  If I so
cared, I could configure the shell to only allow sftp to certain users,
all from the restricted shell.  We should be careful that we always use
the user's shell, for backward compatibility with setups that expect
that their restricted shell actually restricts their users in some way.

> 
> Perhaps I just don't know enough about the protocol--does it even make
> sense to grant subsystem access without granting normal ssh access? It
> seems to work if I make the user's login shell be
> /usr/lib/libexec/sftp-server, so I'm assume it does...

Almost exactly what I do, except that I also allow users to change their
passwords, and have an auto Maildir fixup hack.  I might add a remote
pine option in the future.

> 
> On 24 May 2001 09:17:46 -0500, mouring at etoh.eviladmin.org wrote:
> >
> > There are few issues I need to sort out.  As I said.. symlink and
> > rename commands break under my current patch.  And I need to find a better
> > way of doing error checking.  I'd like to also include the option to
> > 'jail' someone in a subdirectory off their home directory.  Thus removing
> > their ability to modify dot files in their home directory.  But that may
> > require changes to sshd.
> >
> > I'm sure it will work fine.  Just when I get done I'll need a few other
> > people to look over the patch to ensure I did not miss any edge cases.
> >
> > I'll have a more robust patch in a day or two.
> >
> > - Ben
> >
> > On Fri, 25 May 2001, Andrew Bartlett wrote:
> >
> > > Is there any way of making this work?  This is the method I much prefer,
> > > and was looking at implementing a while ago.  I'm glad sombodies taken a
> > > stab at it.
> > >
> > > I run SFTP specificly becouse it does not require a ROOT deamon (apart
> > > from OpenSSH, which I run already) nor does it require a set-uid
> > > binary.  Hence my interest in this patch.
> > >
> > > Andrew Bartlett
> > >
> > > mouring at etoh.eviladmin.org wrote:
> > > >
> > > > Outside the fact that realpath() requires the file aspect of the path to
> > > > exist which breaks 'rename' and 'symlink' =)
> > > >
> > > > - Ben
> > > >
> > > > On Wed, 23 May 2001 mouring at etoh.eviladmin.org wrote:
> > > >
> > > > >
> > > > >
> > > > > On 23 May 2001, Patrick Higgins wrote:
> > > > >
> > > > > > I'm working on setting up a semi-trusted sftp service, and to get it
> > > > > > working, I need chroot capability.
> > > > > >
> > > > > Actually I was looking at it from a different point of view.
> > > > >
> > > > > Instead of requiring setuid sftp-sever and the use of chroot().  Carefully
> > > > > crafted realpath() usage and strncmp() should do the same thing.
> > > > >
> > > > > This is a VERY VERY limited test.  (As in.. compiles.. and looks like it
> > > > > works.=)
> > > > >
> > > > > I know it can be cleaned up.. but it's where I left off in my testing.
> > > > >
> > > > > Markus, is there anything else I should worry about using this method?
> > > > >
> > > > > - Ben
> > > > >
> > > > >

-- 
Andrew Bartlett
abartlet at pcug.org.au



More information about the openssh-unix-dev mailing list