Question about proftpd permissions

[evil_smurf]

I don't know if this is a bug, configuration issue, or just by design, but it appears that no matter who owns a file or what the file permissions are set at, if you login as a user, you have full and total control over every single file in the directory you are in, regardless of who owns the file or what the file permissions are.

I tested this by creating a "temp" file, making root the owner, and then setting the file permissions to 000. I could login as the user whom has the file in their directory and could delete the file without a complaint by the server.

Is Proftpd supposed to behave this way?

 

[blasty]

Im pretty certain that's *not* by design, but more likely a configuration error.
As which user is the proftpd daemon running? As far a I remember it should be able to run as low-privileged user like the 'nobody' account, and will elevate to the proper user once a user authenticates itself.

 

[evil_smurf]

It is running on a low-privilaged user:

aux | grep proftpd
ftp 7595 0.0 0.1 2672 724 ? SNs Mar30 0:00 proftpd: (accepting connections)
arj004 16346 0.0 0.3 2684 1372 ? SN 10:53 0:00 proftpd: arj004 - 158.135.1.57: IDLE
arj004 16347 0.0 0.3 2684 1488 ? SN 10:53 0:00 proftpd: arj004 - 158.135.1.57: IDLE


Here is the permissions for the user folder I am testing this in:

drwx--x--x 4 arj004 arj004 4096 Apr 1 18:48 arj004


proftpd.conf:

ServerName "ProFTPd"
ServerType standalone

Port 21
UseReverseDNS off
TimeoutLogin 120
TimeoutIdle 120
TimeoutNoTransfer 120
TimeoutStalled 120

MaxClients 50
MaxClientsPerUser 3



ScoreboardFile /var/run/proftpd/proftpd.pid

TransferLog /var/log/proftpd/xferlog.legacy
LogFormat default "%h %l %u %t \"%r\" %s %b"
LogFormat auth "%v [%P] %h %t \"%r\" %s"
LogFormat write "%h %l %u %t \"%r\" %s %b"

#DON'T modify this log format. Its used by DirectAdmin to determine user usage
LogFormat userlog "%u %b"
ExtendedLog /var/log/proftpd/65.99.199.112.bytes WRITE,READ userlog

AuthUserFile /etc/proftpd.passwd
DefaultServer on

#AuthPAM

<Global>
DeferWelcome on

RequireValidShell no

DefaultRoot ~
DirFakeUser on ftp
DirFakeGroup on ftp

User ftp
Group ftp
#UserAlias anonymous ftp

AllowStoreRestart on
AllowRetrieveRestart on

Umask 022
DisplayLogin welcome.msg
AllowOverwrite yes
IdentLookups off
ExtendedLog /var/log/proftpd/access.log WRITE,READ write
ExtendedLog /var/log/proftpd/auth.log AUTH auth

#
# Paranoia logging level....
#
#ExtendedLog /var/log/proftpd/paranoid.log ALL default
PassivePorts 61001 65535
</Global>

Include /etc/proftpd.vhosts.conf

 

[nobaloney]

Just tested, and it appears that proftpd ignores ownership in the standard proftpd.conf file as provided by DirectAdmin.

Have you asked about this on a Proftpd forum?

Jeff

 

[evil_smurf]

I have not, haven't really had time.

I'll ask when I get some free time to myself

 

[floyd]

This is not good at all. I even tested on an older DA proftpd configuration from last year and same thing so its not a recent change.

If proftpd allows anyone to delete a file then why did DA have to go to the trouble of changing File Manager to change ownerships? I thought the point was that people were having trouble deleting files created by apache.

I just created a file as root and could delete it. I chowned it to apache and could delete it. This does not make any sense. My proftpd is running as ftp.

 

[floyd]

This is what I found http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Limit.html

One situation that often arises is one where the administrator would like to give users the ability to upload and dowload files from a given directory, but not to be able to delete files from that directory. This cannot be accomplished using normal Unix filesystem permissions, for if a user has write permission on a directory (necessary for uploading files to that directory) they also have delete permissions. In Unix, a directory file serves as a sort of "table of contents", tracking the files in the directory. Adding or removing a file are thus changes on the directory file, and do not involve checking the permissions on the file being added or removed. This is also how a non-root user can delete files that are owned by root and only have user-write permissions.

So what surmised from that is that if the parent folder is owned by the user then the user can delete the file no matter who owns it.

As a test I used the admin account.

I created a file in /home/admin as root and used ftp as admin to delete it.

I chowned /home/admin to root:root and created the file as root and could not delete it.

I chowned the file to admin:admin and still could not delete it as admin.

I chowned /home/admin back to admin:admin and could delete the file.

So the files owned by apache problem was probably because the folder the files were in were owned by apache not the files themselves.

I think everything is still secure as long as the folders are owned by the proper user.