Bug 748996

Summary: Expected behavior of /proc when changing on disk executable permissions during run time.
Product: Red Hat Enterprise Linux 6 Reporter: Travis Gummels <tgummels>
Component: kernelAssignee: Eric Sandeen <esandeen>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2CC: aviro, bfields
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-11 20:05:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 787799    

Description Travis Gummels 2011-10-25 19:46:42 UTC 
Description of problem:

• Shouldn't the perms change with the executable?
• Executable with execute only permissions (111) disallows reading process stats from /proc by user that initiated the executable.
• Changes the permissions on the file on disk have no effect, the running binary stays with its original permissions at time of initiation.
• Theory : The permissions are stored in an inode and the running binary and therefore the reference to it in proc should be references to the on disk inode.
• Assumption : Looks like the kind of thing that might have been done that way to close a security hole.
• Assumption : Copy rather than reference might be done that was to close a subtle security hole.
• Is this a bug?
• Is this an optimization that has some unfortunate side effects?
• Is this something that was done for some non-obvious reason burried within either the VFS or the procfs code?

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


How reproducible:
100%

Steps to Reproduce:

$ cd /tmp/
$ cp /bin/cat .
$ chmod 111 ./cat
$ ./cat /dev/zero >/dev/null &
$ ps ax | grep cat.*zero
Copyright (c) 2011 by Red Hat, Inc. All rights reserved.
1
proc perms don't change with file
16963 pts/3 R+ 0:16 ./cat /dev/zero
16966 pts/0 S+ 0:00 grep cat.*zero
$ ls -l cat
---x--x--x. 1 ben ben 48568 Oct 7 14:34 cat
$ ls /proc/16963/exe
ls: cannot access /proc/16963/exe: Permission denied
$ cat /proc/16963/exe
cat: /proc/16963/exe: Permission denied
$ chmod 755 cat
$ ls -l cat
-rwxr-xr-x. 1 ben ben 48568 Oct 7 14:34 cat
$ cat /proc/16963/exe
cat: /proc/16963/exe: Permission denied
$ ls -l /proc/16963/exe
ls: cannot read symbolic link /proc/16963/exe: Permission denied
lrwxrwxrwx. 1 root root 0 Oct 7 14:40 /proc/16963/exe
$ sudo !!
sudo ls -l /proc/16963/exe
[sudo] password for user:
lrwxrwxrwx. 1 root root 0 Oct 7 14:40 /proc/16963/exe -> /tmp/cat
  
Actual results:
Permissions on executing program do not follow those in the fs.

Expected results:
Permissions on executing program follow those in the file system.

Additional info:
Comment 2 Eric Sandeen 2011-11-02 19:38:13 UTC 
Al, any thoughts on this one?
Comment 4 J. Bruce Fields 2011-11-11 20:05:57 UTC 
In the kernel source, see calls to would_dump() at exec time, which end up setting mm->dumpable differently depending on whether the binary is not readable.  This causes the "dumpable" tests at the end of __ptrace_may_access (called from proc_fd_access_allowed, from proc_pid_readlink(), which is readlink method for any symlink under /proc/$pid/) to fail.

So, the short version: permissions to readlink() a symlink under /proc/$pid/ may depend on whether the binary was readable at the time it was exec'd.

That behavior is by design.

I don't know if there exists a well-defined policy that would recheck file permissions here while avoiding other pitfalls; anyone who wants that would need to write an extremely careful description of such a policy and get it vetted upstream before we could think about implementing it.