From: hooanon05@yahoo.co.jp
To: "David P. Quigley" <dpquigl@tycho.nsa.gov>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/8] Aufs2 documents
Date: Sat, 28 Feb 2009 17:04:12 +0900 [thread overview]
Message-ID: <11466.1235808252@jrobl> (raw)
In-Reply-To: <1235758633.15148.448.camel@moss-terrapins.epoch.ncsc.mil>
"David P. Quigley":
> I mean that in the event that an xattr can't be copied up to the next
> read-write branch the copyup should fail. Otherwise you get the
:::
> I can see an "I know better" mount option being useful for this. I
> understand what you're trying to do now.
Then I don't see difference between what you wrote and my idea.
I think I should assert first that aufs doesn't support xattr currently.
> The point I was trying to make with iso9660_t is that since the xattr
> interface is what is used for security labels regardless of whether the
> underlying file system actually supports xattrs there are other places
> that the security label may come from. Since an iso9660 file system does
> not support extended attributes SELinux has a fixed type for all content
> on that file system. When someone asks for security.selinux on an
> iso9660 file system it goes to the inode, takes the security context in
> there, and converts it into the string you see even though there is no
> real xattr support.
For example, on a system which adopts selinux, if a user copies a file
manually from iso9660 (or other fs which doesn't support xattr) to a
xattr-supported fs, then he will not meet a security risk.
Is it correct?
And in the reverse case, copying a file manually from an xattr-supported
fs to non-supported fs may drop security info. Since this is manual
operation, user should know the risk. Right?
Here what will be security.selinux for the copied file?
Will it be set to the default value which is defined by a global policy
or something?
If it is true, then what will happen when the global policy has the
highest security level? User will not meet a security risk either?
Or such policy is useless in real world because of too low usability?
While these questions may sound silly, I just want to know how the
protection will be damaged in detail. Still I don't know much about
selinux.
I understand the case you want to clarify which aufs copies file
internally instead of manually. But will you tell me the comparision
between internal file copy and manual copy?
Anyway I guess aufs should support xattr in the future. I just want to
fix its priority, particulary it has to be implemented before
review/merge.
J. R. Okajima
prev parent reply other threads:[~2009-02-28 8:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-23 7:31 [RFC 0/8] Aufs2 documents hooanon05
2009-02-23 7:33 ` [RFC 1/8] Aufs2: introduction hooanon05
2009-02-23 7:34 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23 9:13 ` Tomas M
2009-02-23 9:22 ` Tomas M
2009-02-24 8:13 ` New filesystem for Linux kernel Tomas M
2009-02-24 11:52 ` Miklos Szeredi
2009-02-24 13:18 ` hooanon05
2009-02-24 13:45 ` Tarkan Erimer
2009-02-24 13:57 ` hooanon05
2009-02-24 14:16 ` Tarkan Erimer
2009-02-24 14:50 ` Miklos Szeredi
2009-02-24 16:26 ` hooanon05
2009-02-25 10:28 ` Miklos Szeredi
2009-02-26 4:09 ` hooanon05
2009-02-26 5:51 ` hooanon05
2009-02-26 5:55 ` hooanon05
2009-02-24 14:15 ` Theodore Tso
2009-02-24 15:18 ` David P. Quigley
2009-02-24 15:41 ` hooanon05
2009-02-25 15:53 ` David P. Quigley
2009-02-26 4:21 ` hooanon05
2009-02-25 7:31 ` Tomas M
2009-02-25 9:33 ` David Newall
2009-02-25 8:12 ` Tomas M
2009-02-26 14:31 ` Amit Kucheria
2009-02-23 14:23 ` [RFC 2/8] Aufs2: structure hooanon05
2009-02-23 7:35 ` [RFC 3/8] Aufs2: lookup hooanon05
2009-02-23 7:36 ` [RFC 4/8] Aufs2: branch hooanon05
2009-02-23 7:36 ` [RFC 5/8] Aufs2: wbr_policy hooanon05
2009-02-23 7:37 ` [RFC 6/8] Aufs2: fmode_exec hooanon05
2009-02-23 7:37 ` [RFC 7/8] Aufs2: mmap hooanon05
2009-02-23 9:18 ` Tomas M
2009-02-23 14:39 ` hooanon05
2009-02-23 7:38 ` [RFC 8/8] Aufs2: plan hooanon05
2009-02-25 17:50 ` [RFC 0/8] Aufs2 documents David P. Quigley
2009-02-25 19:07 ` Matthew Wilcox
2009-02-26 4:54 ` hooanon05
2009-02-26 17:20 ` David P. Quigley
2009-02-27 14:27 ` hooanon05
2009-02-27 18:17 ` David P. Quigley
2009-02-28 8:04 ` hooanon05 [this message]
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=11466.1235808252@jrobl \
--to=hooanon05@yahoo.co.jp \
--cc=dpquigl@tycho.nsa.gov \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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