From: "J. R. Okajima" <hooanon05@yahoo.co.jp>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Alessandro Pignotti <alexpigna.dev@gmail.com>,
Linux-Fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [Patch] Support overriding uid/gid in overlayfs
Date: Fri, 01 Feb 2013 02:01:53 +0900 [thread overview]
Message-ID: <4997.1359651713@jrobl> (raw)
In-Reply-To: <CAJfpegtYpbBoErC22f1bJQrr_ZZQpredan89DckusBXDoCk6Xw@mail.gmail.com>
Miklos Szeredi:
> One issue, though, is that stat("x") and fd=open("x"); fstat(fd) will
> return different file stats (the fstat one will return the stats for
> the original file). This may confuse some apps.
>
> This is a something a "true" union filesystem can do better that
> union-mounts or overlayfs.
Exactly.
That was one example I picked up and posted when I read overlayfs years
ago.
Recently I named it "name-based union". Of course AUFS is "inode-based
union." stat(2) operates upon a filename while fstat(2) operates upon a
file descriptor. Overlayfs (and probably UnionMount too) may return
different info for these two systemcalls even when they should be equal.
All the inode-based (or file descriptor based) operations can confuse
users in overlayfs, I am afraid. I was looking forward to see how
overlayfs solve this problem.
Overriding uid/gid is an idea, but obviously it will not match using
with system dirs such as /bin and /usr, since they often have suid
binaries. So it will be used only for user dirs which is unioned as
lower RO layer. It might be better to implement such feature into your
lower FS (or generic VFS feature) instead of overlayfs.
If I remember correctly, some non-unix FS such as VFAT already have such
feature.
J. R. Okajima
next prev parent reply other threads:[~2013-01-31 17:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1358254695.3380.16.camel@avalon>
2013-01-25 11:08 ` [Patch] Support overriding uid/gid in overlayfs Miklos Szeredi
2013-01-28 15:58 ` Alessandro Pignotti
2013-01-31 16:15 ` Miklos Szeredi
2013-01-31 17:01 ` J. R. Okajima [this message]
2013-01-31 17:40 ` Miklos Szeredi
2013-02-01 4:45 ` J. R. Okajima
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=4997.1359651713@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=alexpigna.dev@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).