Messages in this thread | | | Date | Thu, 23 Sep 1999 22:39:14 +0200 | From | Kristian Koehntopp <> | Subject | Re: Why is chmod(2)? |
| |
I started this whole discussion with: >I was talking about Unix system security recently and came >across a strange question which you may be able to answer. The >question is: "Why is chmod(2)", i.e. why are there so many >kernel functions which take pathnames as parameters, when there >are similar functions which take an fd.
[ del del del ]
>I think it is often desireable in security related programs to >use the f-version of a systemcall, because it ensures that you >are talking about the same file in a sequence of related calls >that are being done with the intention to check multiple things. >An open fd is the only way for a process to refer directly to an >inode (and a file offset, which is redundant in some cases, but >not harmful).
Rainer Weikusat sent me the following code snippet:
----- #!/bin/bash # # From: Rainer Weikusat <rw@another.de>
cd /tmp
echo -e "#!/bin/sh\necho f1" >f1 echo -e "#!/bin/sh\necho f2" >f2
chmod +x f1 f2 ln -sf f1 f3
exec 3<f3
ln -sf f2 f3
/proc/self/fd/3 -----
which prints "f1". This reminded me of the fact that in Linux all filedescriptors have in fact names in the /proc directory, which kind of turns my original argument around: Since all fds have names, you can actually use the regular system calls to access them and are not required to use the f-calls instead. In his Example, Rainer demonstrates this by emulating the nonexistent fexecve() with a regular execve() on file descriptor 3.
This probably differs from a hypothetical fexecve() system call in the point in time when the permissions are check, but should be sufficient from a security standpoint in most cases. In particular, Apaches suexec.c should be perfectly happy for it.
All that _I_ need now to be happy is an option to execve() that makes execve() ignore any potential SUID bits on a program. I went through great pains and troubles to change to the desired UID in my program and to check the validity of the program I want to execute and I do not want that program to change privileges spontaneously...
Kristian
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |