RE: ftpd STOR and STOU work the same ?
On 05-Jan-2002 Riccardo Torrini wrote:
| On 05-Jan-2002 (19:47:53/GMT) Mike Heffner wrote:
|
|>> I noticed a strange behaviour, sending a file twice create
|>> version even if sunique is off, on all versions I can test.
|
|> This is intentional...
|
| This is black magic. I hate it. I hope this would be (soon)
| documented _OR_ make configurable.
| ...or at least tell me where I can un-patch myself ;)
Sure, it can be made configurable. Unfortunately, our current ftpd doesn't
support a config file like lukeftpd, or others, so it would have to be
implemented as a new argument.
The patch is simple, find the following code in ftpd.c, and just remove
the 'guest' in the first conditional.
void
store(name, mode, unique)
char *name, *mode;
int unique;
{
FILE *fout, *din;
struct stat st;
int (*closefunc) __P((FILE *));
if ((unique || guest) && stat(name, &st) == 0 &&
(name = gunique(name)) == NULL) {
LOGCMD(*mode == 'w' ? "put" : "append", name);
return;
}
...
|
|
|> If you need to upload, and overwrite a file, you might try
|> setting up a restricted user for this purpose, that only
|> has write access to a single directory.
|
| Why? Assume I have a very restricted /incoming dir (111) and
| one or two levels or restricted dir under that (.../foo/bar/)
| also with mode=111, and assume that a file named write-me is
| placed in that dir owned by anonimous, mode +w.
| Nothing can imagine files and dir if is unable to list them,
| so only authorized users or automatic robots can read/write
| under that deep path.
True, as long as the filename is not easily guessable, but it's still
security through obsecurity. ;)
|
| Assume also that I need 2^n (a very large number) different
| users to write on my ftp a sort of report, all the times with
| the same name. I can't delete/put because dir is not writable.
I don't quite follow this, do you have some other method involved to
move/copy the files to another location before the next user logs in and
overwrites the file?
|
| Do you think this is a 'too-crazy' request?
No, feel free to submit a patch.
Mike
--
Mike Heffner
Fredericksburg, VA <[EMAIL PROTECTED]>
msg33423/pgp0.pgp
Description: PGP signature
RE: ftpd STOR and STOU work the same ?
On 05-Jan-2002 (19:47:53/GMT) Mike Heffner wrote: >> I noticed a strange behaviour, sending a file twice create >> version even if sunique is off, on all versions I can test. > This is intentional... This is black magic. I hate it. I hope this would be (soon) documented _OR_ make configurable. ...or at least tell me where I can un-patch myself ;) > If you are running an anonymous file drop, you don't want > guest users to be able to overwrite the files of others... I'm over 18 (really 36 :-). I would like to decide myself. I lost two weeks trying to figure why it doesn't work. > If you need to upload, and overwrite a file, you might try > setting up a restricted user for this purpose, that only > has write access to a single directory. Why? Assume I have a very restricted /incoming dir (111) and one or two levels or restricted dir under that (.../foo/bar/) also with mode=111, and assume that a file named write-me is placed in that dir owned by anonimous, mode +w. Nothing can imagine files and dir if is unable to list them, so only authorized users or automatic robots can read/write under that deep path. Are you following me? Assume also that I am in my home, with my local lan isolated from internet or at work (same as above because ftp is _only_ an internal service). Assume also that I need 2^n (a very large number) different users to write on my ftp a sort of report, all the times with the same name. I can't delete/put because dir is not writable. Do you think this is a 'too-crazy' request? > Mike Thanks for your time, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ftpd STOR and STOU work the same ?
On 04-Jan-2002 Riccardo Torrini wrote: | On 29-Dec-2001 (16:49:06/GMT) Riccardo Torrini wrote: | |> I noticed a strange behaviour, sending a file twice create |> version even if sunique is off, on all versions I can test. | |> This includes: |> - FreeBSD 5.0-CURRENT #0: Sun Dec 9 08:37:55 CET 2001 |> - FreeBSD 4.4-STABLE #6: Fri Oct 12 21:44:36 CEST 2001 |> - FreeBSD 4.5-PRERELEASE #0: Fri Dec 28 18:47:34 CET 2001 |> all updated with cvsup and a fresh installed 4.2 from cdrom: |> - FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 | | Also tested on other versions on the same range (4.2 - 5.0) | and noticed that happens only with anonimous (ftp) user but | _not_ with regular users. Hope this can help... | | Tryed with /etc/inetd.conf standard config where ftpd runs | with -l and with my own custom -llSA, the same. | Tryed from local (ftp localhost) and from remote machine, even | with another OS (hpux and openbsd). The same. I'm really sad. | I'm (pretty) sure isn't a 'pilot-error'. Please comfirm this... | | Thanks again. | This is intentional. If you are running an anonymous file drop, you don't want guest users to be able to overwrite the files of others. If you need to upload, and overwrite a file, you might try setting up a restricted user for this purpose, that only has write access to a single directory. Mike -- Mike Heffner Fredericksburg, VA <[EMAIL PROTECTED]> msg33416/pgp0.pgp Description: PGP signature
RE: ftpd STOR and STOU work the same ?
On 29-Dec-2001 (16:49:06/GMT) Riccardo Torrini wrote: > I noticed a strange behaviour, sending a file twice create > version even if sunique is off, on all versions I can test. > This includes: > - FreeBSD 5.0-CURRENT #0: Sun Dec 9 08:37:55 CET 2001 > - FreeBSD 4.4-STABLE #6: Fri Oct 12 21:44:36 CEST 2001 > - FreeBSD 4.5-PRERELEASE #0: Fri Dec 28 18:47:34 CET 2001 > all updated with cvsup and a fresh installed 4.2 from cdrom: > - FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 Also tested on other versions on the same range (4.2 - 5.0) and noticed that happens only with anonimous (ftp) user but _not_ with regular users. Hope this can help... Tryed with /etc/inetd.conf standard config where ftpd runs with -l and with my own custom -llSA, the same. Tryed from local (ftp localhost) and from remote machine, even with another OS (hpux and openbsd). The same. I'm really sad. I'm (pretty) sure isn't a 'pilot-error'. Please comfirm this... Thanks again. Riccardo. PS: For those which missed original message here is an archived copy (sorry, long line): http://www.GUFI.org/ricerca.php3?mode=show&id=ml:freebsd-current:192316 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ftpd STOR and STOU work the same ?
I noticed a strange behaviour, sending a file twice create version even if sunique is off, on all versions I can test. This includes: - FreeBSD 5.0-CURRENT #0: Sun Dec 9 08:37:55 CET 2001 - FreeBSD 4.4-STABLE #6: Fri Oct 12 21:44:36 CEST 2001 - FreeBSD 4.5-PRERELEASE #0: Fri Dec 28 18:47:34 CET 2001 all updated with cvsup and a fresh installed 4.2 from cdrom: - FreeBSD 4.2-RELEASE #0: Mon Nov 20 13:02:55 GMT 2000 This is my test bed (incoming is writeable, mod=777), following a log with my -CURRENT box (but other versions works the same): # cd /etc && ftp localhost [...anonymous login...] 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> pwd 257 "/" is current directory. ftp> dir 150 Opening ASCII mode data connection for '/bin/ls'. total 1 drwxrwxrwx 2 0 0 512 Dec 29 15:58 incoming 226 Transfer complete. ftp> cd incoming 250 CWD command successful. ftp> dir 150 Opening ASCII mode data connection for '/bin/ls'. 226 Transfer complete. Ok, starting with clean dir. Toggling sunique twice to make sure it is off and sendind a small file: ftp> sunique Store unique on. ftp> sunique Store unique off. ftp> put motd local: motd remote: motd 150 Opening BINARY mode data connection for 'motd'. 100% |***|61 00:00 ETA 226 Transfer complete. 61 bytes sent in 0.00 seconds (19.98 KB/s) ftp> put motd local: motd remote: motd 150 Opening BINARY mode data connection for 'motd.1'. 100% |***|61 00:00 ETA 226 Transfer complete. 61 bytes sent in 0.00 seconds (13.87 KB/s) ftp> dir 150 Opening ASCII mode data connection for '/bin/ls'. total 2 -rw-r--r-- 1 69 0 61 Dec 29 16:02 motd -rw-r--r-- 1 69 0 61 Dec 29 16:02 motd.1 226 Transfer complete. Also tryed with debug enabled (debug command from client) and noticed that server use a different command when in unique mode _but_ either STOR than STOU create a unique file name :-( [...deleting all previous test file, starting with clean dir...] ftp> debug Debugging on (debug=1). ftp> put motd local: motd remote: motd ---> TYPE I 200 Type set to I. ---> EPSV 229 Entering Extended Passive Mode (|||49176|) ---> STOR motd 150 Opening BINARY mode data connection for 'motd'. 100% |***|61 00:00 ETA 226 Transfer complete. 61 bytes sent in 0.00 seconds (18.77 KB/s) ftp> put motd local: motd remote: motd ---> EPSV 229 Entering Extended Passive Mode (|||49177|) ---> STOR motd 150 Opening BINARY mode data connection for 'motd.1'. 100% |***|61 00:00 ETA 226 Transfer complete. 61 bytes sent in 0.00 seconds (18.81 KB/s) ftp> sunique Store unique on. ftp> put motd local: motd remote: motd ---> EPSV 229 Entering Extended Passive Mode (|||49178|) ---> STOU motd 150 Opening BINARY mode data connection for 'motd.2'. 100% |***|61 00:00 ETA 226 Transfer complete (unique file name:motd.2). 61 bytes sent in 0.00 seconds (19.01 KB/s) Yes, also tryed with passive off, all the same. I avoid to send that log, saving a lot of band. And GET works fine, with either unique on or off. I need overwrite to enable upload of a single file to a write disabled dir. Last question: using ftp from command line or from a cron job start with a different passive mode set, maybe a cron job doesn't read login.conf setting? Need explicit passive setting in script? Using ftp -p doesn't set passive mode the same from command line or from cron job. Is this a toggle or a force? Thanks for reading so much. Riccardo. PS: I'm subscribed only to -current, sorry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
