As usual, I got my question answered, and as always, thanks to the many
people who replied.
Original question:
> I've got a problem with ftp on Solaris 2.5.1. It leaves uploaded files
> with mode 666. According to the FAQ, "By default, all daemons inherit the
> umask 0 from init. This is most problematic for a service like ftp, which
> in a standard configuration leaves all uploaded files with mode 666." So,
> I guess it ain't a bug, it's a feature. As a workaround, the FAQ goes on
> to offer the following suggestion:
>
> To get daemons to use another umask execute the following commands in
> /bin/sh and reboot:
>
> umask 022 # make sure umask.sh gets created with the proper mode
> echo "umask 022" > /etc/init.d/umask.sh
> for d in /etc/rc?.d
> do
> ln /etc/init.d/umask.sh $d/S00umask.sh
> done
>
> Note: the trailing ".sh" of the scriptname is important, if you don't
> specify it, the script will will be executed in a sub-shell, not in the
> main shell that executes all other scripts.
>
> I'm nervous about doing this, since it is going to affect all my daemons,
> not just FTP. Is there another daemon out there that'll be depending upon
> the default behavior? Is there a way to change the default mode only for
> ftp?
>
> I've also thought about using wu-ftp, although I'm a bit nervous tinkering
> with ftp on a production system that makes a fair amount of use of it. It
> appears that there'd be a bit of work getting it configured the first time,
> and I haven't found any indication yet that it'll fix this problem.
The consensus was that I could follow the suggestion in the FAQ without
fear. I did, and everything is fine.
Several people pointed out that if I just wanted to change the umask for
ftp only, it would be very easy to write a wrapper.
Casper Dik <casper@holland.Sun.COM> sent all the information I'd need to
create a wrapper, and even included commands in his message that I could
just cut and paste to create the wrapper script. Here's what he sent:
cat > /usr/sbin/in.ftpd-wrapper <<-EOF
#!/sbin/sh
# Umask of 022
umask 022
# No core dumps from ftpd
ulimit -c 0
exec /usr/sbin/in.ftpd
EOF
chmod 755 /usr/sbin/in.ftpd-wrapper
Then edit /etc/inetd.conf and change "/usr/sbin/in.ftpd" to
"/usr/sbin/in.ftpd-wrapper"
Then "kill -HUP `fuser /usr/sbin/inetd`"
======
Alejandro López-Valencia <alejolo@sue.ideam.gov.co> also included a wrapper
as follows:
An alternative: don't point directly to in.ftpd in /etc/inet/inetd.conf but
rather to a shell script wrapping this startup line:
env - umask 022\
PATH='whatever' \
OTHER_VAR='whatever' \
/usr/sbin/in.ftpd $1 $2 $3 $4 $5
So it takes the arguments you give the daemon in /etc/inet/inetd.conf
========
Alejandro also had quite a bit to say about wu-ftpd. I don't have the time
to follow through with his suggestions right now, but I'm including his
comments here with the expectation that someone else will find them useful:
I have used wu-ftpd for six years now in several architectures and it has
never left me down :-). I do have a couple of recommendations.
(1) Use a paranoic /etc/ftpusers list. I have a copy that restricts all
system users as well as other daemonized services I can gladly send you a
copy as soon as I get the chance (and you ask me for it). If you need to
transfer files as root from/to other system it is far better to use SSH r*
utilities.
(2) Use wu-ftpd academ beta 13 or later (it will replace /usr/sbin/in.ftpd
and the man pages so you may want to modify the installation script as the
man pages supplied don't inform on how to set up anonymous ftp services in
solaris); it is available at
ftp://ftp.academ.com/pub/wu-ftpd/private/
the directory is unreadable but if you use a web client to:
... and follow the links you can retreive information on how to grab a copy.
(3) You may want to demonize the server (I think it uses a single-forking
server), there are links to patches in the wu-ftpd FAQ. Or try out NcFTPd at
http://www.probe.net/~mgleason/ncftpd/, the latter is nice but it consumes a
lot of memory (uses a pre-forking scheme) and has a few quirks I wasn't happy
with but in general is superb and you get technical support and a license.
==============
Again, thanks for the help.
Rodney
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:01 CDT