From: Miklos Szeredi <miklos@szeredi.hu>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
Ondrej Mosnacek <omosnace@redhat.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Mark Salyzyn <salyzyn@android.com>,
Paul Moore <paul@paul-moore.com>,
linux-kernel@vger.kernel.org,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org,
Daniel J Walsh <dwalsh@redhat.com>
Subject: Re: overlayfs access checks on underlying layers
Date: Tue, 4 Dec 2018 16:31:09 +0100 [thread overview]
Message-ID: <CAJfpegtFVvq286HAorGLg6ywMsfs51KqaQwFkcuV7Dtu8TLaLg@mail.gmail.com> (raw)
In-Reply-To: <20181204152248.GB21509@redhat.com>
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> Having said that, this still create little anomaly when mknod to client
> is not allowed on context label. So a device file, which is on lower
> and client can not open it for read/write on host, it can now be opened
> for read/write because mounter will allow access. So why it is different
> that regular copy up. Well, in regular copy up, we created a copy of
> the original object and allowed writing to that object (cp --preserve=all)
> model. But in case of device file, writes will go to same original
> object. (And not a separate copy).
That's true.
In that sense copy up of special file should result in upper having
the same label as of lower, right?
Thanks,
Miklos
next prev parent reply other threads:[~2018-12-04 15:31 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 19:55 overlayfs access checks on underlying layers Miklos Szeredi
2018-11-27 19:58 ` Miklos Szeredi
2018-11-27 21:05 ` Vivek Goyal
2018-11-28 10:00 ` Miklos Szeredi
2018-11-28 17:03 ` Vivek Goyal
2018-11-28 19:34 ` Stephen Smalley
2018-11-28 20:24 ` Miklos Szeredi
2018-11-28 21:46 ` Stephen Smalley
2018-11-29 11:04 ` Miklos Szeredi
2018-11-29 13:49 ` Vivek Goyal
2019-03-04 17:01 ` Mark Salyzyn
2019-03-04 17:56 ` Casey Schaufler
2019-03-04 18:44 ` Stephen Smalley
2019-03-04 19:21 ` Amir Goldstein
2018-11-29 16:16 ` Stephen Smalley
2018-11-29 16:22 ` Stephen Smalley
2018-11-29 19:47 ` Miklos Szeredi
2018-11-29 21:03 ` Stephen Smalley
2018-11-29 21:19 ` Stephen Smalley
2018-12-04 13:32 ` Miklos Szeredi
2018-12-04 14:30 ` Stephen Smalley
2018-12-04 14:45 ` Miklos Szeredi
2018-12-04 15:35 ` Stephen Smalley
2018-12-04 15:39 ` Miklos Szeredi
2018-12-11 15:50 ` Paul Moore
2018-12-04 15:15 ` Vivek Goyal
2018-12-04 15:22 ` Vivek Goyal
2018-12-04 15:31 ` Miklos Szeredi [this message]
2018-12-04 15:42 ` Vivek Goyal
2018-12-04 16:05 ` Stephen Smalley
2018-12-04 16:17 ` Vivek Goyal
2018-12-04 16:49 ` Stephen Smalley
2018-12-05 13:43 ` Vivek Goyal
2018-12-06 20:26 ` Stephen Smalley
2018-12-11 21:48 ` Vivek Goyal
2018-12-12 14:51 ` Stephen Smalley
2018-12-13 14:58 ` Vivek Goyal
2018-12-13 16:12 ` Stephen Smalley
2018-12-13 18:54 ` Vivek Goyal
2018-12-13 20:09 ` Stephen Smalley
2018-12-13 20:26 ` Vivek Goyal
2018-12-04 15:42 ` Stephen Smalley
2018-12-04 16:15 ` Vivek Goyal
2018-11-29 22:22 ` Daniel Walsh
2018-12-03 23:27 ` Paul Moore
2018-12-04 14:43 ` Stephen Smalley
2018-12-04 23:01 ` Paul Moore
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=CAJfpegtFVvq286HAorGLg6ywMsfs51KqaQwFkcuV7Dtu8TLaLg@mail.gmail.com \
--to=miklos@szeredi.hu \
--cc=bfields@fieldses.org \
--cc=dwalsh@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=paul@paul-moore.com \
--cc=salyzyn@android.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@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).