Red Hat Bugzilla – Bug 1467309
"Operation not permitted" when creating directory
Last modified: 2017-07-20 10:36:51 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):
The user's home directory is on an NFS share, on EMC Isilon storage.
Steps to Reproduce:
1.Connect to FTP server and authenticate
2.Try to create a directory, e.g. "mkdir test"
FTP server responds with "Operation not permitted"
Directory is created.
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.
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.
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
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?
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
"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.
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")
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?
Apologies for the delay - I can confirm that moving the directory to local storage also corrects the issue.
"Operation not permitted" looks like quite a common issue on non-local filesystems, e.g.
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.
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.