[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
I'm trying to set up a chrooted FTP area for internal use. I'm running
into roadblock after roadblock, and have finally reached the point
where I'm beginning to wonder if I'm going about this wrong.
I started out with a chroot area with an etc/inetd.conf containing just
172.16.0.1:ftp stream tcp4 nowait:120 nobody /usr/libexec/ftpd ftpd -ll -d
Then I started testing and adding things (libraries, mostly) until ftpd
Next problem was that ftpd doesn't tell even the local logs why it
denies access, when it does; I had to add debugging syslog() calls to
figure that out. (Turns out an entry in ftpchroot doesn't allow access
without an entry in ftpusers too.)
Then I ran into the getusershell() idiocy. I call it idiocy because
the interface design is cripplingly broken (there's no way to tell it
"any program is allowed" or "any program in this directory is allowed"
or any such). And ftpd has no configuration knob to say "yes, dammit,
allow this user (or, shell) anyway". So I ripped that code out.
Then it exploded, logging
in openpam_configure(): No required or binding component in service ftpd,
pam_start: system error
I was unable to find any documentation on what this meant or what I
would have to copy over to fix it; in particular, openpam_configure has
no manpage. I even googled for "pam" and "chroot" in netbsd.org,
though I shouldn't have to resort to anything off-system for something
like this. It turned up nothing useful anyway.
Rather than dig through the source to find it, I took this as an excuse
to finally figure out how to make PAM go away (something I've been
meaning to do ever since I discovered 4.0.1 had had PAM inflicted on
it), dusted off an old memory that there was a way to disable PAM
entirely for the whole system, dug a bit, and added MKPAM=no to
/etc/mk.conf. Rebuild ftpd yet again. Sure enough, doesn't try to
link in PAM noww.
Then it wouldn't authenticate because it couldn't read the password
hash. So I did a chmod 644 of spwd.db and master.passwd in the chroot.
It *still* wouldn't authenticate.
Turns out getpwent() refuses to even _try_ to read spwd.db unless
geteuid() returns zero!! And, as far as I can tell, ftpd has no way to
have it use anything but getpwent() to get passwords.
I'd really really prefer to not run ftpd as root inside the chroot.
Should I just stop even trying to use NetBSD's ftpd and look for
something a bit saner, or pull out the machete and wade into ftpd?
Or am I just missing some option that should be jumping off the page at
me but isn't?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |