Messages in this thread |  | | From | Marek Michalkiewicz <> | Subject | Re: setuid scripts (was Re: proc fs and shared pids) | Date | Fri, 27 Sep 1996 17:35:44 +0200 (MET DST) |
| |
Miquel van Smoorenburg: > Trvial check. But, while working on suidexec, I found another problem: > recent Linuxes taint the stuff in the /proc file system. As long as > real and effective uid/gid are different you can't access /proc/<pid>/fd. > Only a setuid/exec pair cleans the "dumpable" flag, as it is called in
Perhaps we can have a pair of syscalls to get/set the dumpable flag for the current process. If the process knows what it is doing, it could set its own dumpable flag. Problem: it's Linux-specific, but so is our /proc...
A syscall to get the dumpable flag could be useful too - for example, to make sure ld.so ignores LD_xxx not only for set[ug]id programs, but also for unreadable ones (otherwise they aren't really unreadable (any user can trick them into executing arbitrary code, which can dump the process address space to a file) - it could be a security problem if there are things like encryption keys compiled in unreadable binaries - there is at least one package which does this: deslogin).
Or maybe we should start working on a "real" /dev/fd filesystem as found on Solaris (possibly other systems too, but I can't check right now). Quoting from Solaris 2.5 fd(4) man page:
These files, conventionally called /dev/fd/0, /dev/fd/1, /dev/fd/2, and so on, refer to files accessible through file descriptors. If file descriptor n is open, these two system calls have the same effect:
fd = open("/dev/fd/n",mode); fd = dup(n);
On these files creat(2) is equivalent to open, and mode is ignored. As with dup, subsequent reads or writes on fd fail unless the original file descriptor allows the operations.
[...]
DIAGNOSTICS open(2) returns -1 and EBADF if the associated file descrip- tor is not open.
One nice thing about these files is that they are really character devices (minor number == fd number), and so they don't need to be tainted (that was necessary to avoid users logging in to their own account using ftp, and having access to all the ftpd's file descriptors. But ftpd allows only access to regular files, not devices.) - /dev/fd/* files on Solaris are all 0666 root.root).
Now, I have tried looking into implementing a /dev/fd/* driver (as described by the Solaris man page), but I'm not sure if it is possible with our current VFS interface. I can have my own low level open() routine, but I can't replace the existing code which does all the "struct file" allocation (unnecessary in this case - we just need the minor number of the device, do a "dup" and return the new file descriptor). Any ideas? (other than a dirty hack: add a check for /dev/fd major directly into the linux/fs/open.c code - but Linus probably wouldn't like it very much ;-)
> Also, when using "ps" you don't see the real > name of the process anymore, but eg. "/bin/sh /proc/19445/fd/3" instead. > To do better would require some kernel support.
If we do the /dev/fd trick in the kernel, we probably can also export the real script name via procfs...
[Another idea, somewhat unrelated: start moving /proc to a new location, so that it doesn't conflict with Solaris /proc, if someone ever implements that for more binary compatibility between SparcLinux and Solaris. For now mount procfs under /proc-linux (or whatever) and keep a symlink /proc -> proc-linux for compatibility until all programs are changed to use /proc-linux; when that is done we can have a Solaris-like /proc. Choosing the same pathname for something that is quite different from other systems was a mistake IMHO... Does Digital Unix also have this /proc filesystem, or is it Solaris-specific?]
Marek
|  |