FTP guest access chroot not working
Hillel
I am trying to setup a user to have limited FTP access on a
OpenServer 5.0.6a system.
I added the "guestuser <username>" line to /etc/ftpaccess
and set the home directory for that user in /etc/passwd to
/ftp/./<startdir> as instructed in the ftpd and ftpaccess man pages.
The /ftp directory is setup for anonymous FTP access.
When logging into ftp as this user, the ftp prompt starts
out in the correct starting directory, but I can still go back
to the root directory of the server. Using a graphical FTP
client I can see the entire directory tree as if there never
was a chroot call.
Is there something else required to get the chroot call to work?
Thanks.
---Hillel
br...@aljex.com
with the stock ftp server, so I'll just go through my entire setup and
maybe you can compare against your own and spot the problem. Pay
attention to such things as the ownershit & permissions modes on
various files & dirs.
I thing the MAIN secret was an incorrect man page that described a
certian option as being on by default and really it's off by default
and you have to edit /etc/inetd.conf and tcp stop ; tcp start to get
the change into effect.
Then you still have the normal non-trivial list of things you must set
up just right.
if I don't mention a files perms or paste a ls output, then it
generally means it's a file that was already there and I just edited
it.
the user name is "someguy"
I have modified /etc/default/accounts so that users home dirs are in
/home, yours will be in /usr
the "root" dir for the chroot is /home/someguy/ftp
I don't claim that every one of these is necessary or even correct,
only that it's what I see on my working box. As we all know, a thing
can work enough to seem fine and still be wrong...
-----
/etc/shells includes:
/bin/false
-----
/etc/passwd includes:
someguy:x:456:102::/home/someguy/./ftp:/bin/false
-----
/etc/group includes:
someguy::102:someguy
-----
/etc/inetd.conf includes:
ftp stream tcp nowait root /etc/ftpd ftpd -a -d -i
-l -L -o -X
-----
/etc/ftpaccess includes:
# chroot ftp users
guestgroup someguy someotherguy yetanotherguy
-----
ls -lR /home/someguy:
total 20
-rw------- 1 someguy group 1193 Nov 19 09:35 .kshrc
-r-------- 1 someguy auth 0 Nov 19 09:36 .lastlogin
-rw------- 1 someguy group 6 Nov 19 09:36 .profile
dr-xr-xr-x 2 root sys 512 Nov 23 10:34 bin
drwxr-xr-x 2 root sys 512 Nov 23 10:50 dev
dr-xr-xr-x 2 root sys 512 Nov 23 12:43 etc
drwxrwxrwx 2 someguy someguy 1024 Mar 23 03:09 ftp
dr-xr-xr-x 2 root sys 512 Nov 23 10:42 lib
dr-xr-xr-x 2 bin bin 512 Nov 23 12:22 shlib
dr-xr-xr-x 3 root sys 512 Nov 23 10:44 usr
/home/someguy/bin:
total 88
---x--x--x 1 root sys 43660 Nov 23 10:34 ls
/home/someguy/dev:
total 0
crw-rw-rw- 1 root sys 35, 0 Jul 22 2004 socksys
crw-rw-rw- 1 root root 23, 0 Jul 22 2004 zero
/home/someguy/etc:
total 4
-r--r--r-- 1 root sys 23 Nov 23 12:43 group
-r--r--r-- 1 root sys 30 Nov 23 12:43 passwd
/home/someguy/ftp:
total 412
-r-------- 1 someguy auth 0 Nov 23 16:06 .lastlogin
[...411 data files that this user has uploaded...]
/home/someguy/lib:
total 370
-r-xr-xr-x 1 bin sys 188312 Nov 23 10:42 libprot.so.1
/home/someguy/shlib:
total 136
-r-xr-xr-x 1 root sys 67751 Nov 23 12:22 libc_s
/home/someguy/usr:
total 2
dr-xr-xr-x 2 root sys 512 Nov 23 10:47 lib
/home/someguy/usr/lib:
total 3694
-r-xr-xr-x 1 bin sys 562076 Nov 23 10:45 libc.so.1
-r-xr-xr-x 1 bin sys 537324 Nov 23 10:47 libresolv.so.1
-r-xr-xr-x 1 bin sys 240228 Nov 23 10:46 libsocket.so.1
-r-xr-xr-x 1 bin sys 537324 Nov 23 10:46 libsocket.so.2
-----
cat /home/someguy/etc/passwd:
someguy:x:456:50::/:/bin/ksh
-----
cat /home/someguy/etc/group:
someguy::102:someguy
-----
cat /home/someguy/.profile
exit
-----
all those files / directories / files I listed under /home/someguy were
either created by the initial useradd -m command, created manually
according to the TA found on the sco web site, or copied from the
equivalent place in the base OS. Note: when you copy those files, you
need to copy the real files, not the symlinks!
example: the base OS "/bin/ls" is really just a symlink to
/opt/K/SCO/Unix/5.0.6Ga/bin/ls
so when creating the new chroot env, I used the tar command with the -L
option and a little "files" file as a quicky way to gather all the
necessary files, pasted right from that TA, and get the directories
created all in one easy, repeatable, shot.
ie:
jailfiles:
----
/bin/ls
/etc/passwd
/etc/group
/lib/libprot.so.1
/usr/lib/libc.so.1
/usr/lib/libsocket.so.1
/usr/lib/libsocket.so.2
/usr/lib/libresolv.so.1
/dev/socksys
/dev/zero
/shlib/libc_s
-----
and then ran:
tar cvLfF - jailfiles |compress -H >jail.tar.Z
cd /home/someguy
zcat /jail.tar.Z |tar xvAf -
It's possible I used cpio instead or maybe had to manually create the
/dev files with mknod.
And I think that's it.
I see one discrepency right off, the users group in the users chrooted
copy of /etc/passwd doesn't match anything else, but, it doesn't seem
to be impacting anything we happen to care about.
The user can upload/download files at will in his chroot jail, and
cannot get out of that jail.
When you log in as this user, you can see /usr /etc /usr/bin /usr/lib
etc... but it's only the skeleton copy in the chroot jail not the real
ones. if you created a symlink inside the jail that points to some real
file outside the jail, then when your are logged in via ftp, the file
is just a broken link, you really do not have any access to anything
outside that jail.
Additionally, this is a ftp-only account. The user cannot login via
telnet or ssh or facetwin.
enjoy :)
If that was too easy then come back for round 2, I have also set up
chroot jailed sftp-only accounts on 506 using a patched version of
openssh. they can't even ftp in, *only* sftp, only protocol-2, only
blowfish, only dsa keys. Of course the same users who demanded "make it
ultra ultra secure!!!" did nothing but complain how "complicated" it
was to get an sftp client and ssh keys set up ...
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Hillel
> Not sure what you are missing, but I have this working on a 5.0.6 box
> with the stock ftp server, so I'll just go through my entire setup
and
> maybe you can compare against your own and spot the problem. Pay
> attention to such things as the ownershit & permissions modes on
> various files & dirs.
>
> I thing the MAIN secret was an incorrect man page that described a
> certian option as being on by default and really it's off by default
> and you have to edit /etc/inetd.conf and tcp stop ; tcp start to get
> the change into effect.
>
The problem was that the "ftpd" was not using the "-a" option
by default like it used to. I just had to add the option to
inetd.conf and send the HUP signal to the inetd process.
Thanks.
---Hillel