Hide Forgot
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:
Al, any thoughts on this one?
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.