mr@cica.indiana.edu (Michael Regoli) (05/07/91)
][ When logging into many hosts allowing anonymous ftp access, the message "Guest login ok, access restrictions apply" appears upon a successful login. However, it remains to be seen what restrictions are in effect. For example, in a public uploads area (owned by ftp, mode 777), ftp users can "put" and "get" files, in addition to "dele" and "append" to files. It is the latter cases that oftentimes destroys data in a public area. What measures can be applied via BSD ftpd to restrict access to certain ftp commands? More specifically, how can files in a public area be "protected" (*and* still remain public) from damage by other anonymous ftp-ers? (Thankfully ftp won't allow files to "collide" that have the same name.) Thanks for any help... -- michael regoli mr@cica.indiana.edu regoli@iubacs.BITNET
jik@athena.mit.edu (Jonathan I. Kamens) (05/07/91)
In article <1991May6.190230.10494@cica.indiana.edu>, mr@cica.indiana.edu (Michael Regoli) writes: |> When logging into many hosts allowing anonymous ftp access, the |> message "Guest login ok, access restrictions apply" appears upon a |> successful login. However, it remains to be seen what restrictions |> are in effect. The access restrictions are that your UID is the anonymous ftp UID (which, presumably, can be prevented from accessing some files by not turning on the world access bits and not adding the ftp user to the group the files are in), and that your root directory has been chroot()d to the ftp home directory. This means that if the ftp home directory in /etc/passwd is /usr/spool/ftp, then you can only access files and directories in /usr/spool/ftp and its subdirectories. This is documented in the man page ftpd(8). |> What measures can be applied via BSD ftpd to restrict access to |> certain ftp commands? More specifically, how can files in a public |> area be "protected" (*and* still remain public) from damage by other |> anonymous ftp-ers? (Thankfully ftp won't allow files to "collide" |> that have the same name.) Don't make the files world-writeable. Don't make them owned by the ftp UID. If you want to have a drop-off location like /contrib where people can put stuff, you should make the directory world-executable and world-writeable, but not world-readable. This will allow anonymous ftp contributors to put files into it, but not to list the files in it unless they know the names of those files. Then, you occasionally have to scan this directory as a UID that can read it (e.g. root or whomever owns the directory) and copy files out of it into a world-readable directory if you want to save them. This has several advantages, including the fact that you know what is being made available on your machine, so you can't get sued when people use your machine's anonymous ftp directory as a drop-off point for illegal information of some sort. Or just for information that takes up many meg of disk space that you can't spare. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
mr@ogre.cica.indiana.edu (Michael Regoli) (05/07/91)
In <1991May6.190230.10494@cica.indiana.edu> mr@cica.indiana.edu (Michael Regoli) writes: >][ >When logging into many hosts allowing anonymous ftp access, the >message "Guest login ok, access restrictions apply" appears upon a >successful login. However, it remains to be seen what restrictions >are in effect. For example, in a public uploads area (owned by ftp, >mode 777), ftp users can "put" and "get" files, in addition to "dele" >and "append" to files. It is the latter cases that oftentimes >destroys data in a public area. >What measures can be applied via BSD ftpd to restrict access to >certain ftp commands? Thanks to everyone for contacting me. Here's a temporary solution that seems to work: For obvious reasons, I need the directory for "uploads" to be mode 777 so ftp-er's can place files anytime. What works is to chown the uploads directory to "root" and add the sticky bit to mode 777 on the directory. In order to protect the files from being "stomped," chown the files to anything other than root or ftp. (Since ftpd does a chroot, without the sticky bit set, it will delete ANY file, with ANY ownership, that is placed in a directory that is mode 777.) Of course, files that are placed prior to a "chown" are owned by ftp and therefore can be destroyed by anonymous ftp-ers. Not much we can do about it. (Well, of course, we could have cron visit the directory on a regular basis to chown the files, but we don't get *that* far behind in moving files out of the public uploads area.) Anyhow, this entire exercise has been useful in learning the nuances of Unix file permissions and ftp/ftpd. My thanks again to everyone. -- michael regoli mr@cica.indiana.edu regoli@iubacs.bitnet ...rutgers!iuvax!cica!mr -- michael regoli mr@cica.indiana.edu regoli@iubacs.BITNET ..rutgers!iuvax!cica!mr