Re: [PATCH] new syscall: flink

H. Peter Anvin
2003-04-07T14:46:37Z

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