public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ulrich Drepper <drepper@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] new syscall: flink
Date: Mon, 07 Apr 2003 17:23:41 -0700	[thread overview]
Message-ID: <3E92168D.6060700@redhat.com> (raw)
In-Reply-To: <b6scsk$18b$1@penguin.transmeta.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> If you really really think you need this (and not just do it because
> some random idiot-customer doesn't understand security), then I would
> suggest you add a O_CANLINK flag to open, and require that that flag is
> set in the file descriptor.

Nobody would be stupid enough to let me work on customer issues related
to the kernel.  The requests come in through glibc users.

Anyway, there are two or three ways I can see:

- - add safelink() instead of flink()

   int safelink (const char *oldname, int fd, const char *newname)

  As Jakub explained, this syscall would check that the file referenced
  by oldname really corresponds to fd before making the link.

  If you need an example, take the linker.  The linking can take a long
  time.  The temporary output file has to be created early and there is
  sometimes enough time before the linking finished for even a human
  to figure out the temporary file's name and replace the file.  If then
  the final file is installed as root (since the linking succeeds)
  you'll have problems.

  There is of course the possibility that one compares the ino/dev of
  the temporary file and the file after the link (or rename, btw) but
  this means the wrong output file existed for some time and all that
  is left to do is to remove the file which might be critical if the
  system depends on the file always being present.


- - add the O_CANLINK.  Sure it's possible.  But see the next variant


- - add an open() flag to create files which are not present in the
  filesystem (Hurd has something like this).  open() would get as the
  filename the name of a directory.  Such a feature can be
  used for all kinds of temporary files:

  + files which never need names, i.e., don't have to be accessed
    through the filesystem; the advantage is that there would never
    be stray files in the filesystem if the program forgets to clean
    them up

  + temp files which have to be completed first before renamed.  Here
    flink() and frename() would introduce the name in the filesystem.
    This is obviously useful in many many places, e.g., the linker
    scenario.  There is no way to attack the linker while it is doing
    its work since the output file isn't visible until it is installed
    under the final name.

  Maybe the O_CANLINK flag idea is also necessary for this, don't know.
  The O_ANONYMOUS flag might include setting O_CANLINK.


I'm certainly not qualified to say whether this is viable or not.  The
safelink() idea certainly is implementable, just 3-4 more lines on top
of the flink() patch.  But this wouldn't be necessary if we'd have the
more complete support with the new open() flag(s).  Al mentioned to me
some problems with network filesystem in the context of flink().  So
somebody who understands these issues might want to comment.  It seems
there is some interest in this.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+khaN2ijCOnn/RHQRAm09AJ9Fin1Js+Qla9vVSRzawSASl0dCNACfdoU1
VxrcNGyC06OxRiQZ0+reo0k=
=PosI
-----END PGP SIGNATURE-----


  parent reply	other threads:[~2003-04-08  0:22 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-06 18:39 [PATCH] new syscall: flink Ulrich Drepper
2003-04-07 17:35 ` Linus Torvalds
2003-04-07 20:37   ` H. Peter Anvin
2003-04-08  0:23   ` Ulrich Drepper [this message]
  -- strict thread matches above, loose matches on Subject: below --
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-07  2:56 Mark Grosberg
2003-04-07  3:39 ` H. Peter Anvin
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
     [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-07  9:01 Clayton Weaver
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 23:57 Chuck Ebbert
2003-04-08 13:06 Chuck Ebbert
2003-04-10  0:31 Clayton Weaver
2003-04-10 22:10 Clayton Weaver
2003-04-11  1:02 ` David Wagner
2003-04-11 17:11 Clayton Weaver

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=3E92168D.6060700@redhat.com \
    --to=drepper@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox