#637076 AllowOverwrite On doesn't work with UserOwner and GroupOwner directives

Package:
proftpd-basic
Source:
proftpd-dfsg
Submitter:
Date:
2021-06-22 04:15:02 UTC
Severity:
normal
Tags:
#637076#5
Date:
2011-08-08 10:51:01 UTC
From:
To:
Directive "AllowOverwrite On"  doesn't work in such config:

# cat /etc/proftpd/proftpd.conf
Include /etc/proftpd/modules.conf

<Global>
  AllowOverwrite on
</Global>

UseIPv6 off

UseReverseDNS     off
Port 0

SystemLog                       /var/log/proftpd/proftpd.log

   <IfModule mod_lang.c>
    LangPath /usr/share/locale
    LangDefault en_US
   </IfModule>

<VirtualHost x.x.x.x>
   <IfModule mod_cap.c>
     # Allow root to use chown(2)
     CapabilitiesEngine      off
     #CapabilitiesSet -CAP_CHOWN
   </IfModule>

ServerName "x ftp server"
Port 21
DefaultServer           on
ServerAdmin             x@x
IdentLookups off
MaxClients 30 "Sorry, max %m users -- try again later"
TimeoutLogin 60
TimeoutIdle 300
TimeoutNoTransfer 300
TimeoutStalled 1800
DefaultTransferMode binary
DeferWelcome off
Umask 022
DefaultRoot ~ !andron
AllowStoreRestart on
RequireValidShell off
User www-data
Group www-data
   <Directory ~/*>
         UserOwner www-data
         GroupOwner www-data
         AllowOverwrite  on
         <Limit WRITE READ DIRS STOR SITE_CHMOD>
                 AllowAll
         </Limit>
   </Directory>

</VirtualHost>

But work if I comment UserOwner and GroupOwner directives it's works:

# cat /etc/proftpd/proftpd.conf
Include /etc/proftpd/modules.conf

<Global>
  AllowOverwrite on
</Global>

UseIPv6 off

UseReverseDNS     off
Port 0

SystemLog                       /var/log/proftpd/proftpd.log

   <IfModule mod_lang.c>
    LangPath /usr/share/locale
    LangDefault en_US
   </IfModule>

<VirtualHost x.x.x.x>
   <IfModule mod_cap.c>
     # Allow root to use chown(2)
     CapabilitiesEngine      off
     #CapabilitiesSet -CAP_CHOWN
   </IfModule>

ServerName "x ftp server"
Port 21
DefaultServer           on
ServerAdmin             x@x
IdentLookups off
MaxClients 30 "Sorry, max %m users -- try again later"
TimeoutLogin 60
TimeoutIdle 300
TimeoutNoTransfer 300
TimeoutStalled 1800
DefaultTransferMode binary
DeferWelcome off
Umask 022
DefaultRoot ~ !andron
AllowStoreRestart on
RequireValidShell off
User www-data
Group www-data
   <Directory ~/*>
         #UserOwner www-data
         #GroupOwner www-data
         AllowOverwrite  on
         <Limit WRITE READ DIRS STOR SITE_CHMOD>
                 AllowAll
         </Limit>
   </Directory>

</VirtualHost>
#637076#10
Date:
2017-02-26 21:57:36 UTC
From:
To:
On 08.08.2011 12:51, Андрей Василишин wrote:

Hi,

https://bugs.debian.org/637076
Are you still able to reproduce the problem? Could you share some logs,
which are eventually useful?

Hilmar
#637076#13
Date:
2017-02-26 21:57:36 UTC
From:
To:
On 08.08.2011 12:51, Андрей Василишин wrote:

Hi,

https://bugs.debian.org/637076
Are you still able to reproduce the problem? Could you share some logs,
which are eventually useful?

Hilmar
#637076#18
Date:
2018-05-05 09:44:45 UTC
From:
To:
On 08.08.2011 12:51, Андрей Василишин wrote:

Hi,
Posted this as question in the proftp forum for now.

https://forums.proftpd.org/smf/index.php/topic,12361.0.html

Hilmar
#637076#23
Date:
2020-12-21 15:43:05 UTC
From:
To:
tags 637076 + upstream confirmed
quit

This is seems still pending with 1.3.7a. With a very simple global
configuration:

/etc/proftpd/conf.d/groupowner.conf:

<Directory /tmp/tmp>
AllowOverwrite on
GroupOwner nogroup
UserOwner nobody
</Directory>

vagrant@debian:~$ lftp -u vagrant localhost
Password:
lftp vagrant@localhost:~> cd /tmp/tmp
cd ok, cwd=/tmp/tmp
lftp vagrant@localhost:/tmp/tmp> ls
-rw-r--r--   1 nobody   nogroup      2259 Dec 21 15:34 local.yml
lftp vagrant@localhost:/tmp/tmp> put local.yml
put: Access failed: 550 local.yml: Permission denied

The intended behavior should be allowing the rewrite of the file, instead.
#637076#32
Date:
2021-06-22 04:06:24 UTC
From:
To:
I believe that the scenario described here:

http://bugs.proftpd.org/show_bug.cgi?id=4418#c5

might capture/describe this bug, in which case, it would fall under "working as expected".

TJ