From: "Clayton Weaver" <cgweav@email.com>
To: wa@almesberger.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] new syscall: flink
Date: Wed, 09 Apr 2003 19:31:16 -0500 [thread overview]
Message-ID: <20030410003116.9596.qmail@email.com> (raw)
----- Original Message -----
From: Werner Almesberger <wa@almesberger.net>
Date: Mon, 7 Apr 2003 15:43:03 -0300
To: Clayton Weaver <cgweav@email.com>
Subject: Re: [PATCH] new syscall: flink
> Clayton Weaver wrote:
> > If the client process subsequently flink()s to the inode, it is merely
> > a zerocopy file copy.
> As far as access to the data is concerned, yes. But there's also the
> location of the file. E.g. this might enable you to fill somebody
> else's quota, or, if distinct physical devices can be be covered by
> the same file system, to access a physical device that would
> otherwise not be available to you.
> Example: I write some kind of RAID mounted at /world, that contains
> my disk under /world/disk, and some Flash storage under /world/flash.
> I protect /world/flash against writes by other people. If a
> read-only FD could be turned into something writeable, some malicious
> creature could "wear out" my Flash by writing to it a lot of times.
> - Werner
I'm wondering about the semantics of the unlink
of the last directory entry and subsequent
flink(). When is the inode updated?
I presume that the open fd has owner and mode
information from open(), but would flink()update the inode with new owner information if the
last directory reference had already been
unlinked, and how would this interact with
owner information associated with the open fd
for subsequent file operations? Would fchmod() then succeed, even if the new process is not
owned by the original owner of the flink()ed
to inode? Are any changes to the inode data
delayed until after close()?
What about multiple flink()s before an inode
update has appeared in the filesystem?
It seems to me that "change of owner of the inode" via flink() is an issue, and application programmers that unlink the last directory reference and then pass the open fd to another process had better have no sentimental attachment to the existing access constraints on the file. flink(), close(), open() isn't exactly a difficult hoop to jump through, even if you've passed an
open fd for a read-only file (that you unlinked
any directory references to).
Regards,
Clayton Weaver
<mailto: cgweav@email.com>
--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
next reply other threads:[~2003-04-10 0:19 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-10 0:31 Clayton Weaver [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-11 17:11 [PATCH] new syscall: flink Clayton Weaver
2003-04-10 22:10 Clayton Weaver
2003-04-11 1:02 ` David Wagner
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-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
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=20030410003116.9596.qmail@email.com \
--to=cgweav@email.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wa@almesberger.net \
/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