Description of problem: ### ### This needs to be addressed asap, as it breaks almost any production servers out there. ### Proftpd uses the wrong userid to access the home directory of a virtual user. This occures since last night, due to an update caused by the patch for AllowChrootSymlinks CVE ( or any other change coming with it ) As you can see in the strace at the end, for the first access to the users designated home directory in this case "/opt/root/home/brainwork/public_html" , uid 1000 guid 1001 is used, which is correct! but for the second try: [pid 32571] setgid(1001) = 0 [pid 32571] geteuid() = 0 [pid 32571] setresgid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 99, -1) = 0 [pid 32571] lstat("/opt/root/home/brainwork/public_html", 0x7ffee3d84dd0) = -1 EACCES (Permission denied) "nobody" is used and this has to fail, because nobody does not have any permissions to access a users home directory. As soon as "nobody" gets into a group used by the apache user to access userhome directories, proftpd starts to work again, confirming, that "nobody" is used to access the home directory. Conlusion: The above strace shows, that at least the correct gid wants to be set, but it gets overwritten by "nobody(99)". This needs to be addressed asap, as it breaks almost any productions servers out there. Version-Release number of selected component (if applicable): proftpd-mysql-1.3.5e-1.fc24.x86_64 proftpd-1.3.5e-1.fc24.x86_64 Compile-time Settings: Version: 1.3.5e (maint) Platform: LINUX [Linux 4.9.13-100.fc24.x86_64 x86_64] Built: Mon Apr 10 2017 14:56:42 UTC How reproducible: works only if you use virtual user from a mysql db. Actual results: Access denied , because uid 99 ( nobody ) is used Expected results: using the actual uid to access the users home directory. Additional info: # grep -E "(uid|gid|lstat|1000)" /tmp/log [pid 32571] geteuid() = 0 [pid 32571] setresgid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 0, -1) = 0 [pid 32571] setresgid(-1, 0, -1) = 0 [pid 32571] geteuid() = 0 [pid 32571] setresgid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 0, -1) = 0 [pid 32571] setresgid(-1, 1001, -1) = 0 [pid 32571] setresuid(-1, 1000, -1) = 0 [pid 32571] lstat("/", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0 [pid 32571] lstat("/opt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 [pid 32571] lstat("/opt/root", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 [pid 32571] lstat("/opt/root/home", {st_mode=S_IFDIR|0755, st_size=20480, ...}) = 0 [pid 32571] lstat("/opt/root/home/brainwork", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 [pid 32571] lstat("/opt/root/home/brainwork/public_html", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 [pid 32571] geteuid() = 1000 [pid 32571] setresuid(-1, 0, -1) = 0 [pid 32571] setresgid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 0, -1) = 0 [pid 32571] setresgid(-1, 0, -1) = 0 [pid 32571] setgid(1001) = 0 [pid 32571] geteuid() = 0 [pid 32571] setresgid(-1, 99, -1) = 0 [pid 32571] setresuid(-1, 99, -1) = 0 [pid 32571] lstat("/opt/root/home/brainwork/public_html", 0x7ffee3d84dd0) = -1 EACCES (Permission denied) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=32571, si_uid=0, si_status=0, si_utime=0, si_stime=0} --- lstat("/etc/shutmsg", 0x7ffee3d85cb0) = -1 ENOENT (No such file or directory)
Update: The Patch for "AllowChrootSymlinks" is the source of the problem. "AllowChrootSymlinks on" allows the login again. note: NO SYMLINKS are involved in the test for this bugreport. There is NO reason, to deny access, if or if this option is not enabled. I reproduced the issue on another system: This is the homedir used: /opt/root/home/cloud-foode/public_html no Links involved : drwxr-xr-x 4 cloud-foode cloud-foode 4096 2. Feb 15:30 /opt/root/home/cloud-drwxr-x--- 12 cloud-foode services 4096 10. Nov 22:37 /opt/root/home/cloud-foode drwxr-xr-x. 12 root root 4096 23. Mär 14:19 /opt/root/home drwxr-xr-x 11 root root 4096 10. Feb 2015 /opt/root drwxr-xr-x 4 root root 4096 10. Feb 2015 /opt but still: 2017-04-19 14:56:11,671 proftpd[6868] X.X.X.X (93.223.221.176[93.223.221.176]): FTP session opened. 2017-04-19 14:56:14,189 proftpd[6868] X.X.X.X (93.223.221.176[93.223.221.176]): error: unable to check /opt/root/home/cloud-foode/public_html: Permission denied 2017-04-19 14:56:14,189 proftpd[6868] X.X.X.X (93.223.221.176[93.223.221.176]): error: unable to determine DefaultRoot directory
Raised upstream: http://bugs.proftpd.org/show_bug.cgi?id=4306
Do you have SELinux in enforcing mode? I see that there's some security attribute set on /opt/root/home (trailing "." on permissions string). If proftpd is unable to determine whether or not that is a symlink, it assumes that it may be one. Perhaps SELinux or some other mechanism is preventing a getattr() on that directory?
SEL is not involved there.
What's the attribute on /opt/root/home? There don't seem to be any such attributes on the other directories.
[root@sXX ~]# attr -l /opt/root/home Attribute "selinux" has a 33 byte value for /opt/root/home [root@sXX ~]# attr -g selinux /opt/root/home attr_get: No data available Konnte "selinux" von /opt/root/home nicht lesen (could not read "selinux" from /o/r/h [root@sXX ~]# stat /opt/root/home Datei: '/opt/root/home' Größe: 20480 Blöcke: 48 EA Block: 4096 Verzeichnis Gerät: ca01h/51713d Inode: 2097153 Verknüpfungen: 423 Zugriff: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Zugriff : 2017-05-02 00:05:00.327423508 +0200 Modifiziert: 2017-04-25 12:01:55.000000000 +0200 Geändert : 2017-04-25 13:29:11.814216996 +0200 Geburt : - # stat -f /opt/root/home Datei: "/opt/root/home" ID: bf2a077579d64c98 Namenslänge: 255 Typ: ext2/ext3 Blockgröße: 4096 Fundamentale Blockgröße: 4096 Blöcke: Gesamt: 64216689 Frei: 18691209 Verfügbar: 15423433 Inodes: Gesamt: 16318464 Frei: 12864001
OK, we have a patch from upstream that should address this. Can you give this scratch build a try? https://koji.fedoraproject.org/koji/taskinfo?taskID=19385528
sure, i will try it out asap.
tried it: works for me
proftpd-1.3.5e-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6bfa33dd9d
proftpd-1.3.5e-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6bfa33dd9d
proftpd-1.3.5e-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.