Re: [PATCH 00/16] Permit filesystem local caching [try #3]

[Casey Schaufler]

--- David Howells <dhowells@xxxxxxxxxx> wrote:

> These patches add local caching for network filesystems such as NFS and AFS.
> 
> FS-Cache now runs fully asynchronously as required by Trond Myklebust for
> NFS.
> 
> --
> Changes:
> [try #3]:
> 
>  (*) Added missing file to CacheFiles patch.
> 
>  (*) Made new security functions return errors and pass actual return data
> via
>      argument pointer.
> 
>  (*) Cleaned up NFS patch.
> 
>  (*) The 'fsc' flag must now be passed to NFS mount by the string options.
> 
>  (*) Split the NFS patch into three as requested by Trond.
> 
> [try #2]:
> 
>  (*) The CacheFiles module no longer accepts directory fds in its cull and
>      inuse commands from cachefilesd.  Instead it uses the current working
>      directory of the calling process as the basis for looking up the object.
>      Corollary to this, fget_light() no longer needs to be exported.
> 

How would you expect an LSM that is not SELinux to interface with
CacheFiles? You have gone to a great deal of effort to support the
requirements of an SELinux system, and that's good, but you have
extended the LSM interface to expose SELinux data structures (secids)
and require them for the operation of CacheFiles, and that's bad.
The data used within an LSM is private to the LSM, and this applies
to SELinux as well as to any other LSM that may come along, such
as the Smack LSM I'm working on. This applies to task data as well
as file data. Further, the behavior of the system in the presence
of an LSM should be controlled by the LSM, it is more than a little
scary that CacheFiles is enforcing SELinux policy based on secids
that may be coming from a different LSM.

I applaud the integration of CacheFiles with SELinux. Unfortunately,
you've done so using the LSM interface in such a way that an LSM
other than SELinux is likely to demonstrate inappropriate behaviors
in the presence of CacheFiles because you have so carefully integrated
the SELinux requirements.

If the integration with SELinux is important to you, and I would
expect that it is given the work you've put into it, I suggest that
the SELinux specific behaviors be identified so that another LSM
can provide the behavior appropriate to the policy it chooses to
enforce and put that into SELinux with an LSM interface. I know
that you're looking at a significant effort to do that, but I
wouldn't think that you'd want CacheFiles to behave badly in the
presence of an LSM that doesn't happen to be SELinux.

I also know it's tempting to point out the SELinux is the only
upstream LSM. I hope to change that before too long, and I know
there are others with ambitions as well. I would not like to see
CacheFiles have to get excluded in the presence of other LSMs
and I doubt you would either.


Casey Schaufler
casey@xxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/