All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] new syscall: flink
Date: 6 Apr 2003 20:39:59 -0700	[thread overview]
Message-ID: <b6qruf$elf$1@cesium.transmeta.com> (raw)
In-Reply-To: Pine.BSO.4.44.0304062250250.9407-100000@kwalitee.nolab.conman.org

Followup to:  <Pine.BSO.4.44.0304062250250.9407-100000@kwalitee.nolab.conman.org>
By author:    Mark Grosberg <mark@nolab.conman.org>
In newsgroup: linux.dev.kernel
> 
> > > Suppose I give you an O_RDONLY handle to a file which you then
> > > flink and gain write access too ?
> >
> > This, I believe, is the real issue.  However, we already have that
> > problem:
> 
> As far as I understand it, isn't the protection information stored in the
> inode? The flink call is just linking an inode into a directory that the
> caller has write access to. The permissions and ownership of the file
> shouldn't change.
> 

The problem is when you get passed a file descriptor from another
process (via exec or file-descriptor passing) and you don't have
permissions to access the *directory*.

My example, though, shows that we have this problem already.

> > int main(int argc, char *argv[])
> > {
> >   int rfd, wfd;
> >   char filebuf[PATH_MAX];
> >
> >   rfd = open("testfile", O_RDONLY|O_CREAT, 0666);
> >   /* Now rfd is a read-only file descriptor */
> 
> There is nothing stopping the caller from re-opening the to-be flinked()
> file descriptor read-write using its name if the caller has permissions.
> So I don't see why that case is different.

Again, permissions on the directory.

	-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

  reply	other threads:[~2003-04-07  3:28 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-07  2:56 [PATCH] new syscall: flink Mark Grosberg
2003-04-07  3:39 ` H. Peter Anvin [this message]
2003-04-07  7:29   ` Miquel van Smoorenburg
2003-04-07  8:18     ` Olivier Galibert
2003-04-07  8:35       ` Jakub Jelinek
2003-04-07  9:11         ` Olivier Galibert
2003-04-07 11:13           ` Alan Cox
2003-04-07 12:31           ` Roman Zippel
2003-04-07 12:54             ` Andreas Schwab
2003-04-07 13:19               ` Roman Zippel
2003-04-07 20:55   ` Fredrik Tolf
2003-04-07 21:43     ` Ulrich Drepper
2003-04-07 22:17       ` Fredrik Tolf
2003-04-07 22:25         ` Ulrich Drepper
2003-04-07 22:55           ` Fredrik Tolf
  -- strict thread matches above, loose matches on Subject: below --
2003-04-11 17:11 Clayton Weaver
2003-04-10 22:10 Clayton Weaver
2003-04-11  1:02 ` David Wagner
2003-04-10  0:31 Clayton Weaver
2003-04-08 13:06 Chuck Ebbert
2003-04-07 23:57 Chuck Ebbert
2003-04-07 16:50 Clayton Weaver
2003-04-07 17:11 ` Arjan van de Ven
2003-04-07 17:37 ` David Wagner
2003-04-07 18:43 ` Werner Almesberger
2003-04-08  5:06   ` Werner Almesberger
2003-04-07 20:35 ` H. Peter Anvin
2003-04-07  9:01 Clayton Weaver
     [not found] <20030407102005.4c13ed7f.manushkinvv@desnol.ru>
     [not found] ` <200304070709.h37792815083@mozart.cs.berkeley.edu>
2003-04-07  7:35   ` Vitaly
2003-04-07 14:57     ` H. Peter Anvin
2003-04-07 18:47       ` Wichert Akkerman
2003-04-07 20:05       ` Bill Rugolsky Jr.
2003-04-07 20:32         ` H. Peter Anvin
2003-04-06 19:05 Dan Kegel
2003-04-06 19:07 ` Dan Kegel
2003-04-06 19:56 ` Oliver Neukum
2003-04-06 20:08   ` Malcolm Beattie
2003-04-06 20:33     ` Oliver Neukum
2003-04-06 21:12   ` Alan Cox
2003-04-07  2:33     ` H. Peter Anvin
2003-04-07  2:29       ` David Wagner
2003-04-07  9:09         ` Malcolm Beattie
2003-04-07 11:02           ` Olivier Galibert
2003-04-07  5:25       ` H. Peter Anvin
2003-04-07  6:43         ` David Wagner
2003-04-07  6:21           ` Vitaly
2003-04-07 16:17           ` Shaya Potter
2003-04-06 18:39 Ulrich Drepper
2003-04-07 17:35 ` Linus Torvalds
2003-04-07 20:37   ` H. Peter Anvin
2003-04-08  0:23   ` Ulrich Drepper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='b6qruf$elf$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.