On 7/28/2013 1:40 AM, Dave Quigley wrote:
On 7/26/2013 6:55 AM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/25/2013 06:45 PM, James Hogarth wrote:
On 25 Jul 2013 19:55, "Daniel J Walsh" <dwalsh@xxxxxxxxxx
<mailto:dwalsh@xxxxxxxxxx>> wrote:
<snip>
The only provisos/additions I could suggest on the above then is to make
it clear in the release notes that server and client should be
matching for
any additional fcontext rules to eliminate any server/client relabel
discrepancies.
In addition rather than defaulting to the file_t context might I suggest
using the current/standard nfs_t context for unknown labels (unless
overridden by mount options of course)?
I am not sure we can do this. Eric do you know of a way to do
something like this?
I don't believe this is possible with our current implementation. I'd
need to look again. The caveat for this operating mode in the IETF
specification we wrote is the the policies are homogenous in this
environment. The server is not really label aware. Its mostly supposed
to be simple attribute storage. In our case here it is aware however
because we don't currently have any policy translation infrastructure it
is supposed to be a homogenous environment.
Dave
Also another tidbit of information. Currently the server has no idea
what the security context of the process making the filesystem call to
an NFS mount. The next phase of Labeled NFS is to work on implementing
RPCSECGSSv3 which among other useful features allows us to assert the
security context of the calling process from the client. So its not
possible for the server to make truely informed decisions about NFS calls.
Dave
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
