Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: [PATCH] new syscall: flink | Date | 7 Apr 2003 07:57:08 -0700 |
| |
Followup to: <20030407113534.1de8dc91.agri@desnol.ru> By author: Vitaly <agri@desnol.ru> In newsgroup: linux.dev.kernel > > On Mon, 7 Apr 2003 00:09:01 -0700 (PDT) > David Wagner <daw@cs.berkeley.edu> wrote: > > > > > >mkdir("testdir", 0700) = 0 > > > > >open("testdir/testfile", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 > > > > >write(3, "Ansiktsburk\n", 12) = 12 > > > > >close(3) = 0 > > > > >open("testdir/testfile", O_RDONLY) = 3 > > > > >chmod("testdir", 0) = 0 > > > > >open("/proc/self/fd/3", O_RDWR) = 4 > > > > >write(4, "Tjo fidelittan hatt!\n", 21) = 21 > > > > > open("/proc/self/fd/3", O_RDWR) -- i thought, it just makes a copy for fd/3, and fd/3 should have the same permissions as it was opened. > > > > > > It should have the same permissions, but it doesn't. Try the sample code! > > This looks like a security hole to me. > > Yep, you are write it's a big hole but it's not a security hole. >
That is what people are arguing it is. It is certainly a *potential* security hole. There are two possibilities:
a) Either flink() is harmless and we should be able to add it.
b) This is a security hole, in which case /proc needs to be fixed. In particular, the open("/proc/self/fd/3", O_RDWR) in my example above should return EPERM.
> It is mistake of abstraction. ls show file in /proc/self/fd as > symbolic links and kernel tries to work with it as symbolic > links. Because there will be a problem when program can access file > from cwd but cannot access from absolute path, also after chroot and > after changing cwd. Therefore it just test permissions of the file > and don't checks any directories in the path. It works as a program > doing smth like that: cd testdir open testfile open /proc/self/fd/3 > (in mind: open testfile again) > > it was a choice of proceed, and it's a bad choice. > I think that "open("/proc/self/fd/3", O_RDWR)" should forget anything about "testdir/testfile" and should only check permissions for proc/self/fd/3. > using your test program i got > open("testfile", O_RDONLY) = 3 > open("/proc/self/fd/3", O_RDWR) = 5
You've clearly changed it around; the file descriptor should be 4.
> and ls /proc/self/fd: > l-wx------ 3 -> /.../testfile > lrwx------ 5 -> /.../testfile > > my proceed: if fd 3 have permission l-wx------ it cannot be opened for reading anyway only for writing and execution.
You'd think, but it doesn't work that way. By the way, I get:
lr-x------ 1 hpa eng 64 Apr 7 07:54 3 -> /home/hpa/flink/testdir/testfile lrwx------ 1 hpa eng 64 Apr 7 07:54 4 -> /home/hpa/flink/testdir/testfile
... not l-wx------ which would be an O_WRONLY file descriptor.
Personally I would prefer if open() on /proc/*/fd would actually operate as if a dup() on the relevant file descriptor, which would be a significant change of semantics; however, one could argue those are the saner semantics.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |