Bug 1467309 - "Operation not permitted" when creating directory
"Operation not permitted" when creating directory
Status: NEW
Product: Fedora EPEL
Classification: Fedora
Component: proftpd (Show other bugs)
el6
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Itamar Reis Peixoto
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-03 07:07 EDT by John Beranek
Modified: 2017-07-20 10:36 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Beranek 2017-07-03 07:07:20 EDT
Description of problem:

When trying to create a directory using an authenticated FTP session, the error below is shown:

ncftp ...ents/fivetel/Picselect > mkdir jbtest2
MKD jbtest2 failed; [jbtest2: Operation not permitted]
Could not mkdir jbtest2: server said: jbtest2: Operation not permitted

Version-Release number of selected component (if applicable):

proftpd-1.3.3g-10.el6.x86_64

The user's home directory is on an NFS share, on EMC Isilon storage.

How reproducible:

Every time.

Steps to Reproduce:
1.Connect to FTP server and authenticate
2.Try to create a directory, e.g. "mkdir test"

Actual results:

FTP server responds with "Operation not permitted"

Expected results:

Directory is created.

Additional info:

Directory in which the new directory is being created in has the permissions "drwxrwsrwx".

If I revert proftpd to "proftpd-1.3.3g-7.el6.x86_64" the problem goes away.
Comment 1 Paul Howarth 2017-07-03 07:16:25 EDT
I see there's a SGID bit on the parent directory there; is the authenticated user a member of the group to which that directory belongs?

The update to proftpd-1.3.3g-8.el6.x86_64 related to propagation of SGID bits (#1297264) so may be related.
Comment 2 John Beranek 2017-07-03 08:13:48 EDT
OK, interesting, the FTP user is *not* a member of the group of the directory.

In fact (this system is inherited!) the user's primary GID is not even defined in /etc/group
Comment 3 Paul Howarth 2017-07-03 09:00:31 EDT
If you try a directory that doesn't have the SGID bit set, does that work? Likewise, if the GID is one that the user is a member of?
Comment 4 John Beranek 2017-07-03 09:57:12 EDT
OK, I can confirm that either fixing the group of the directory, or removing the SGID bit fixes the issue.

i.e. It only gives the error if the parent directory has the SGID bit set, and the user doesn't belong in the directory's group
Comment 5 Paul Howarth 2017-07-03 10:36:17 EDT
"Operation not permitted" (rather than "Permission denied") sounds like an SELinux response or capabilities issue. Are you using SELinux on this system?

Does the documentation for proftpd's mod_cap (http://www.proftpd.org/docs/modules/mod_cap.html) look relevant to your configuration? Note that EL-6's version of proftpd doesn't know about CAP_FSETID though.
Comment 6 John Beranek 2017-07-03 11:30:37 EDT
SELinux is disabled on the system.

We've not configured anything for mod_cap. The only thing "unusual" on the system is that system users are authenticated with sssd/OpenLDAP.

FTP users are (for now) local users.

(Completely off-topic, but sssd/OpenLDAP users can't login to proftpd, even though PersistentPasswd is set to "off")
Comment 7 Paul Howarth 2017-07-11 11:27:47 EDT
I created an EL-6 VM with a couple of local users, made a directory owned by user1, group user1, permission 2777, logged in with proftpd 1.33g-10.el6 as user2 (not a member of group user1) and was able to create a subdirectory without issue, correctly inheriting the group user1.

Do you get the same error if you use local directories rather than NFS shares?
Comment 8 John Beranek 2017-07-17 07:13:10 EDT
Apologies for the delay - I can confirm that moving the directory to local storage also corrects the issue.
Comment 9 Paul Howarth 2017-07-19 10:41:27 EDT
"Operation not permitted" looks like quite a common issue on non-local filesystems, e.g.

https://forums.proftpd.org/smf/index.php?topic=11596.0
https://forums.proftpd.org/smf/index.php?topic=11997.0

A couple more questions:

Are you using mod_vroot? Does using it make any difference?

Is your NFS configuration doing root-squashing?

There's a related patch attached to http://bugs.proftpd.org/show_bug.cgi?id=3963 but I don't think it's likely to help in this case, though I suppose we could try it.
Comment 10 Paul Howarth 2017-07-20 10:36:51 EDT
Just tried proftpd-1.3.3g-10.el6.x86_64 on a CentOS 6 VM accessing an area served by NFS (v3) from a Fedora 25 server.

Doing a mkdir in a directory mode 2755 with gid not a group that the user was in resulted in directory creation success with same gid as parent directory but no SGID bit set on newly-created directory.

If the gid of the parent directory was of a group that the logged-in user was a member of, the directory was created successfully again but this time the SGID bit was inherited by the newly-created directory.

I'm really struggling to reproduce the behaviour you're seeing.

Note You need to log in before you can comment on or make changes to this bug.