Bug 1443507

Summary: wrong uid used for accessing home directory : no login possible
Product: [Fedora] Fedora Reporter: customercare
Component: proftpdAssignee: Paul Howarth <paul>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 24CC: itamar, matthias, paul
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: proftpd-1.3.5e-2.fc24 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-05-12 19:23:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description customercare 2017-04-19 11:52:19 UTC
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)

Comment 1 customercare 2017-04-19 13:04:16 UTC
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

Comment 2 Paul Howarth 2017-04-19 19:21:47 UTC
Raised upstream:
http://bugs.proftpd.org/show_bug.cgi?id=4306

Comment 3 Paul Howarth 2017-05-01 10:26:02 UTC
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?

Comment 4 customercare 2017-05-01 17:15:30 UTC
SEL is not involved there.

Comment 5 Paul Howarth 2017-05-01 19:40:31 UTC
What's the attribute on /opt/root/home?

There don't seem to be any such attributes on the other directories.

Comment 6 customercare 2017-05-01 22:07:59 UTC
[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

Comment 7 Paul Howarth 2017-05-03 08:19:40 UTC
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

Comment 8 customercare 2017-05-03 09:26:56 UTC
sure, i will try it out asap.

Comment 9 customercare 2017-05-03 12:49:38 UTC
tried it: works for me

Comment 10 Fedora Update System 2017-05-03 15:14:48 UTC
proftpd-1.3.5e-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6bfa33dd9d

Comment 11 Fedora Update System 2017-05-04 20:01:46 UTC
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

Comment 12 Fedora Update System 2017-05-12 19:23:46 UTC
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.