Discussion:
[Proftpd-user] Umask and Allowoverwrite
Gregor Streng
2003-11-16 18:42:10 UTC
Permalink
Hello all,

I've some troubles with the Umask directive in conjunction with
Allowoverwrite.

I've understood that ProFtpd will not create files with the execute flag
on.
That's ok with me and under stable from a security point of view.

But why is it that when I upload already existing files / overwrite
files that those files lose their original ownership and permissions.

I would make sense to me if Proftpd does handle overwrite in a that way

- delete existing file
- create file

In that case surely there is a way configuring Proftpd to maintain
ownership and permissions of existing files.
At least I hope so.

Help is highly appreciated.


Kind Regards,
Gregor Streng
TJ Saunders
2003-11-16 18:59:29 UTC
Permalink
gregor>But why is it that when I upload already existing files /
gregor>overwrite files that those files lose their original
gregor>ownership and permissions.

What does your full proftpd.conf look like? What does server debugging
output show?

gregor>I would make sense to me if Proftpd does handle overwrite in a that way
gregor>
gregor> - delete existing file
gregor> - create file

Both in the case of restarted upload and in the case of an append, the
destination file is considered "overwritten"; however, deleting the
existing file in these cases would not be desirable.

Cheers,
TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Music, the greatest good that mortals know,
And all of heaven we have below.

-Joseph Addison

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gregor Streng
2003-11-16 21:31:01 UTC
Permalink
Hello
Post by TJ Saunders
What does your full proftpd.conf look like?
My full proftpd.conf is quite standard and looks like that

ServerName " FTP"
ServerType inetd
DefaultServer off
AccessGrantMsg "Access granted for %u."
UseReverseDNS off
TimeoutIdle 1000
TimesGMT off
ServerIdent off
AllowRetrieveRestart on
AllowStoreRestart on
AuthPAMAuthoritative off


# We don't want to allow any commands with % being sent to the server
DenyFilter "%"

# Port 21 is the standard FTP port.
Port 21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 002

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances 30

# Set the user and group under which the server will run.
User nobody
Group nobody

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
#DefaultRoot ~

<Global>
DefaultChdir /home/skitest/
DefaultRoot /
# having to delete before uploading is a pain ;)
AllowOverwrite yes

DeleteAbortedStores off
RootLogin off
HiddenStor on
IdentLookups off
ListOptions "-a"

</Global>

<Directory /*>
<Limit ALL>
AllowUser skitest
</Limit>
</Directory>
Post by TJ Saunders
What does server debugging
output show?
That's what my server debugging show during file overwrite (debug level
5)

dispatching LOG_CMD command 'LIST' to mod_log
dispatching LOG_CMD command 'LIST' to mod_ls
dispatching PRE_CMD command 'PORT xx,xxx,xxx,xxx,149,201' to mod_core
dispatching PRE_CMD command 'PORT xx,xxx,xxx,xxx,149,201' to mod_core
dispatching CMD command 'PORT xx,xxx,xxx,xxx,149,201' to mod_core
dispatching LOG_CMD command 'PORT xx,xxx,xxx,xxx,149,201' to mod_log
dispatching PRE_CMD command 'STOR test.pl' to mod_core
dispatching PRE_CMD command 'STOR test.pl' to mod_core
dispatching PRE_CMD command 'STOR test.pl' to mod_xfer
in dir_check_full(): path = '/home/skitest/test.pl', fullpath =
'/home/skitest/test.pl'.
in dir_check_full(): setting umask to 0002 (was 0002)
Complex path, will rename /home/skitest/.in.test.pl. to
/home/skitest/test.pl.
dispatching CMD command 'STOR test.pl' to mod_xfer
active data connection opened - local : xx.xxx.xxx.xxx:20
active data connection opened - remote : xx.xxx.xxx.xxx:38345
dispatching LOG_CMD command 'STOR test.pl' to mod_log
dispatching LOG_CMD command 'STOR test.pl' to mod_xfer
Transfer completed: 2801 bytes in 0.13 seconds


The file has been set to 775 by SITE chmod before overwriting it
(debug level 5)

dispatching PRE_CMD command 'SITE chmod 775 test.pl' to mod_core
dispatching PRE_CMD command 'SITE chmod 775 test.pl' to mod_core
dispatching PRE_CMD command 'SITE chmod 775 test.pl' to mod_site
dispatching CMD command 'SITE chmod 775 test.pl' to mod_site
in dir_check_full(): path = '/home/skitest/test.pl', fullpath =
'/home/skitest/test.pl'.
dispatching POST_CMD command 'SITE CHMOD 775 test.pl' to mod_site
dispatching LOG_CMD command 'SITE CHMOD 775 test.pl' to mod_log
.
.
.
.

Hope this help

Thanks
Gregor
TJ Saunders
2003-11-17 05:30:25 UTC
Permalink
gregor> HiddenStor on

This is the cause.

gregor>dispatching PRE_CMD command 'STOR test.pl' to mod_xfer
gregor>in dir_check_full(): path = '/home/skitest/test.pl', fullpath =
gregor>'/home/skitest/test.pl'.
gregor>in dir_check_full(): setting umask to 0002 (was 0002)
gregor>Complex path, will rename /home/skitest/.in.test.pl. to
gregor>/home/skitest/test.pl.

Here, the file being created/written to is not test.pl, for you are using
HiddenStores; the file being written to is .in.test.pl. Once the upload
is completed, the HiddenStore file is renamed to be the actual destination
file (test.pl); the file already existing there is gone (including its
permissions). You might try turning off your use of HiddenStores, if
possible.

Hope this helps,
TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Know thyself.

-Anonymous

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gregor Streng
2003-11-17 09:43:02 UTC
Permalink
Hello again,
Post by Gregor Streng
HiddenStor on
This is the cause.
Here, the file being created/written to is not test.pl, for you are
using
Post by Gregor Streng
HiddenStores; the file being written to is .in.test.pl. Once the
upload
Post by Gregor Streng
is completed, the HiddenStore file is renamed to be the actual
destination
Post by Gregor Streng
file (test.pl); the file already existing there is gone (including its
permissions). You might try turning off your use of HiddenStores, if
possible.
This did the trick now it's working as expected.

Thank your very much.

Regards
Gregor

Loading...