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
Subject: Re: [PATCH v2 1/1] OverlayFS: Fix checking permissions during lookup.
Date: Sun, 28 Feb 2016 12:09:42 +0100 [thread overview]
Message-ID: <20160228110942.GA19509@zenon.in.qult.net> (raw)
In-Reply-To: <20160226194143.GB13054@redhat.com>
On Fri, Feb 26, 2016 at 02:41:43PM -0500, thus spake Vivek Goyal:
> CCing linux-fsdevel as it is a wider issue.
>
>
> On Wed, Feb 24, 2016 at 02:55:52PM +0100, Ignacy Gaw�dzki wrote:
> > Add alternate lookup_one_len_check function to fs/namei.c which does
> > what lookup_one_len did until now with a boolean argument telling
> > whether to check that the base directory is traversable. Modify
> > original lookup_one_len function to call the former with true as the
> > last argument.
> >
> > In function ovl_lookup_real, file fs/overlayfs/super.c, call
> > lookup_one_len_check with false as the last argument, so that failure
> > to traverse the base directory does not return -EACCES. This should
> > make lookup resolution work properly in the following setup
> >
> > drwxr-xr-x lower/
> > drwx------ lower/foo/
> > drw-r--r-- lower/boo/bar
> > drwxr-xr-x upper/
> > drwxr-xr-x upper/foo/
> >
> > when any user not being the owner of lower/foo is trying to access
> > foo/bar in the mounted overlay.
>
> So what's the problem we are trying to solve. Why should we able to
> override the DAC checks of lower layer if same directory in upper
> is searchable for user but it is not searchable in lower layer.
My point is that an overlay filesystem should have consistent
semantics. The current state of affairs fails in this regard on two
points. First, suppose you have the same lower as above, but upper is
empty. Then initially, foo/ has permissions 700 and shouldn't be
traversable by anyone but user root and the owner of foo/. But if user
root or the owner changes foo's permissions to 755, a foo directory is
created in the upper layer and we arrive at the exact same
configuration as above. In this case, I don't think anyone would
expect other users be denied traversal of foo to access bar. Second,
the state of the cache shouldn't have any influence on the way access
rights are enforced. In the present case, traversal of foo is granted
to other users depending on whether the owner or root already accessed
bar.
Besides, according to Documentation/fs/overlay.txt:
Only the lists of names from directories are merged. Other content
such as metadata and extended attributes are reported for the upper
directory only. These attributes of the lower directory are hidden.
which implies that lower's permissions of foo should be ignored if foo
exists in upper as well.
Cheers,
Ignacy
--
Ignacy Gaw�dzki
R&D Engineer
Green Communications
next prev parent reply other threads:[~2016-02-28 11:09 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 [this message]
2016-02-29 16:25 ` Vivek Goyal
2016-02-29 16:54 ` Ignacy Gawędzki
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=20160228110942.GA19509@zenon.in.qult.net \
--to=ignacy.gawedzki@green-communications.fr \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--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).