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.

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);


|> 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 Heffner     <mheffner@[acm.]vt.edu>
  Fredericksburg, VA   <[EMAIL PROTECTED]>

Attachment: msg33423/pgp00000.pgp
Description: PGP signature

Reply via email to