[Proftpd-user] SITE UTIME not working with group permissions

[Peter Andersson]

I'm having trouble with the "SITE UTIME" command. It works perfectly on
user ownership, but it doesn't work on group ownership.

For example, the ftp user is:

User: ftpuser
Group: ftpgroup

UTIME works on a file with this ownership:

User: ftpuser
Group: anygroup
Permissions: 777

But UTIME gives a 555 permission denied on a file with this ownership:

User: anyuser
Group: ftpgroup
Permissions: 777

Does anyone know what might be wrong?
Thanks!

/Peter


Here's the config file for this (test)account;

<Anonymous /Volumes/gemensam/Material>
User ftpuser
Group ftpgroup

DirFakeUser on ftpuser

<Limit RNTO>
AllowAll
</Limit>

<Limit RMDIR>
AllowAll
</Limit>

<Limit MKDIR>
AllowAll
</Limit>

<Limit SITE_UTIME>
AllowUser TurbinSync
AllowAll
</Limit>

<Limit SITE_CHMOD>
AllowAll
</Limit>

RequireValidShell off
AnonRequirePassword on

# Limit the maximum number of anonymous logins

MaxClients 40

# We want 'welcome.msg' displayed at login, and '.message' displayed

# in each newly chdired directory.

DisplayLogin welcome.msg
DisplayChdir .message

</Anonymous>

[TJ Saunders]

Post by Peter Andersson
I'm having trouble with the "SITE UTIME" command. It works perfectly on
user ownership, but it doesn't work on group ownership.
User: ftpuser
Group: ftpgroup
User: ftpuser
Group: anygroup
Permissions: 777
User: anyuser
Group: ftpgroup
Permissions: 777
Does anyone know what might be wrong?

Ah yes, this does sound familiar. We encountered the same underlying
problem for the MFMT command (which also modifies the file mod times):

http://bugs.proftpd.org/show_bug.cgi?id=3577

Looks like a similar workaround (i.e. manually check for group
memberships, fallback to using root privs if possible) might be needed
for the SITE UTIME command.

There is one thing to check beforehand, though: does your ProFTPD have
the mod_cap module present? If so, then Linux capabilities might also
be interfering. Thus you might try adding the following to your
proftpd.conf:

<IfModule mod_cap.c>
# Disable capabilities entirely
CapabilitiesEngine off
</IfModule>

Or, if you want to keep the Linux capabilities restricted, but try to
allow the utimes(2) system call to succeed in cases like this:

<IfModule mod_cap.c
CapabilitiesEngine on
CapabilitiesSet +CAP_FOWNER
</IfModule>

If the above mod_cap tweaks help, please let me know -- I'll update the
mod_site_misc docs with a FAQ/example covering this case. And if not,
I'll look into modifying its code to do what the mod_facts module does
for the MFMT command.

Cheers,
TJ

[Peter Andersson]

Thanks for the quick reply!
I don't have mod_cap installed. So it's not interfering with the
privileges.
Just to make sure I applied your config:

<IfModule mod_cap.c>
# Disable capabilities entirely
CapabilitiesEngine off
</IfModule>

And restarted the server. But I still encounter the same problem.
Thank you so much for helping out!

/Peter

Post by TJ Saunders

Post by Peter Andersson
I'm having trouble with the "SITE UTIME" command. It works perfectly on
user ownership, but it doesn't work on group ownership.
User: ftpuser
Group: ftpgroup
User: ftpuser
Group: anygroup
Permissions: 777
User: anyuser
Group: ftpgroup
Permissions: 777
Does anyone know what might be wrong?

Ah yes, this does sound familiar. We encountered the same underlying
http://bugs.proftpd.org/show_bug.cgi?id=3577
Looks like a similar workaround (i.e. manually check for group
memberships, fallback to using root privs if possible) might be needed
for the SITE UTIME command.
There is one thing to check beforehand, though: does your ProFTPD have
the mod_cap module present? If so, then Linux capabilities might also
be interfering. Thus you might try adding the following to your
<IfModule mod_cap.c>
# Disable capabilities entirely
CapabilitiesEngine off
</IfModule>
Or, if you want to keep the Linux capabilities restricted, but try to
<IfModule mod_cap.c
CapabilitiesEngine on
CapabilitiesSet +CAP_FOWNER
</IfModule>
If the above mod_cap tweaks help, please let me know -- I'll update the
mod_site_misc docs with a FAQ/example covering this case. And if not,
I'll look into modifying its code to do what the mod_facts module does
for the MFMT command.
Cheers,
TJ
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[TJ Saunders]

Post by Peter Andersson
Thanks for the quick reply!
I don't have mod_cap installed. So it's not interfering with the
privileges.
<IfModule mod_cap.c>
# Disable capabilities entirely
CapabilitiesEngine off
</IfModule>
And restarted the server. But I still encounter the same problem.
Thank you so much for helping out!

Well, it was worth a try. :) I've filed a ticket to track this, so that
I don't forget:

http://bugs.proftpd.org/show_bug.cgi?id=4284

Cheers,
TJ

[Peter Andersson]

Thanks a lot TJ!

This is why the open source (sorry if those words rubs you the wrong
way, but I couldn't think of a better word) community is the best!
You just don't get this kind of support elsewhere.

/Peter

Post by TJ Saunders

Post by Peter Andersson
Thanks for the quick reply!
I don't have mod_cap installed. So it's not interfering with the
privileges.
<IfModule mod_cap.c>
# Disable capabilities entirely
CapabilitiesEngine off
</IfModule>
And restarted the server. But I still encounter the same problem.
Thank you so much for helping out!

Well, it was worth a try. :) I've filed a ticket to track this, so that
http://bugs.proftpd.org/show_bug.cgi?id=4284
Cheers,
TJ
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html