From: "Ignacy Gawędzki" <ignacy.gawedzki@green-communications.fr>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
David Howells <dhowells@redhat.com>
Subject: Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup.
Date: Mon, 29 Feb 2016 17:54:40 +0100 [thread overview]
Message-ID: <20160229165440.GA28299@zenon.in.qult.net> (raw)
In-Reply-To: <20160229162546.GA3335@redhat.com>
On Mon, Feb 29, 2016 at 11:25:46AM -0500, thus spake Vivek Goyal:
> I agree that semantics should be more consistent. I don't know that
> if upper layer should override lower layer checks or not.
>
> One could also argue that if root did chown, then changes effectively
> happened in upper layer and anything in upper layer should become
> visible to unpriviliged user but not the one in lower layer.
>
> I just don't know. I guess those who have more background on this
> could pitch in and clarify that was is supposed to be the design
> intention.
>
> [...]
>
> Right, but it does not say anything about what happens to DAC checks
> at lower layer. IOW, it does not say that if lower directory owner
> is different then whether files from that directory will become searchable
> or not.
I suppose that looking at these questions from the perspective of the
primary application of OverlayFS, i.e. embedded systems with lower
being some read-only SquashFS and upper being read-write, may give
some good intuition on how this should work. If the root user changes
access rights to some directories, then it is natural that permissions in
upper are less restrictive than permissions in lower and this in no
way breaks any security. If you're thinking about what happens if
some overlay is mounted where the more permissive directory in upper
shadows a less permissive one in lower, then well, the only user able
to mount such an overlay, i.e. root, should know what she's doing.
Anyway, DAC checks should be consistent from the standpoint of
userland, first and foremost.
--
Ignacy Gaw�dzki
R&D Engineer
Green Communications
next prev parent reply other threads:[~2016-02-29 16:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160224135552.GB8422@zenon.in.qult.net>
2016-02-26 19:41 ` [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup Vivek Goyal
2016-02-27 10:40 ` Nazarov Sergey
2016-02-29 16:32 ` Vivek Goyal
2016-02-28 11:09 ` Ignacy Gawędzki
2016-02-29 16:25 ` Vivek Goyal
2016-02-29 16:54 ` Ignacy Gawędzki [this message]
2016-03-17 15:23 ` Miklos Szeredi
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=20160229165440.GA28299@zenon.in.qult.net \
--to=ignacy.gawedzki@green-communications.fr \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=vgoyal@redhat.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;
as well as URLs for NNTP newsgroup(s).