From: Richard Miller <9fans@hamnavoe.com>
To: 9fans@9fans.net
Subject: [9fans] ramfs bug
Date: Mon, 15 Aug 2022 12:02:02 +0100 [thread overview]
Message-ID: <b4062425dbbe5784ec520d08214bd64f@hamnavoe.com> (raw)
Deleting an open file on ramfs(4) can have surpising results.
Here's how it's supposed to behave. When a file is removed, the
Ram struct which represents the in-memory file has its busy flag
reset, so a subsequent i/o will see that it's been deleted.
cpu% ramfs
cpu% echo this is x >/tmp/x
cpu% { sleep 10; cat } </tmp/x &
cpu% rm /tmp/x
cpu% cat: error reading <stdin>: file does not exist
However, before the i/o takes place, it's possible for another
file to be created and re-use the same Ram struct, setting
the busy flag again. The process which had the deleted file open
is now doing i/o to a different file, without any checks on its
permissions, exclusive use flag, etc.
cpu% ramfs
cpu% echo this is x >/tmp/x
cpu% { sleep 10; cat } </tmp/x &
cpu% rm /tmp/x; echo actually this is y >/tmp/y
cpu% actually this is y
A simple fix is to add a reference count to the Ram struct, to
keep track of how many Fids point to it, and only allow a Ram to
be re-used if both busy==0 and ref==0. The new 9legacy patch
ramfs-refcount makes this change.
Note to 9front users: don't worry, your ramfs is a completely
different program using the 9p(2) library, which doesn't have
this flaw.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tc364b766ff6473bc-M52976e87f40d78ae095f576e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
next reply other threads:[~2022-08-15 11:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-15 11:02 Richard Miller [this message]
2022-08-15 14:20 ` adr
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=b4062425dbbe5784ec520d08214bd64f@hamnavoe.com \
--to=9fans@hamnavoe.com \
--cc=9fans@9fans.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;
as well as URLs for NNTP newsgroup(s).