The layers within the VFS are probably not very clearly defined, but I
think one can fairly clearly see a difference between a "filesystem"
layer and a "namespace" layer.

The vfs_XX function are (in my mind) the top of the filesystem layer.
They primarily call the relevant xxx_operation and just add minimal
support code to enforce standard policy, callouts, etc.

vfsmnts are very much part of the "namespace" layer.  The heart of
this layer is probably link_path_walk.  It allows mounts to tie
filesystems together in all sorts of interesting knots :-)

The readonly-bind-mount concept adds new functionality in the
namespace layer.
The filesystem layer already has a concept of readonly mounts, and
this doesn't change (I hope).  The superblock still has a readonly
flag and the vfs_XXX operations must (possibly indirectly) still test
this flag.

readonly-bind-mounts adds a new 'readonly' flag in the namespace
layer.

So if you want to centralise the code for implementing this
functionality (which seems like a good idea), it should probably
go in link_path_walk, or one of it's friends, rather than in vfs_XXX.

Maybe a new LOOKUP_WRITEACCESS flag which arranges that mnt_want_write
gets called as appropriate, and that path_put will call mnt_drop_write
if needed.

Maybe some enhancement to the 'intent' structure with a similar
effect could be done instead.

Then you could, presumably, put a security hook somewhere in
link_path_walk for those modules (like AppArmor) which want to do
checks based on the namespace.

=========

I just had a look at the places where mnt_want_write is currently
called.  There are quite a few of them.

Two that surprised me were touch_atime and file_update_time.

It is not clear to me that we should avoid updating 'atime' if the
bindmount is marked readonly.  The file is still being accessed, so
updating the atime could still be appropriate.
Possibly a "noatime" per-vfsmnt flag would be appropriate.  But I'm
not convinced that interpreting ...
[ message continues ]

I think link_path_walk() is not a good place to insert new LSM hooks
for pathname based access control (AppArmor and TOMOYO) purpose because

  (1) The kernel don't know what operation (open/create/truncate etc.) will be
      done at the moment of link_path_walk().

  (2) Not all operations call link_path_walk() before these operations
      are done. For example, ftruncate() doesn't call link_path_walk().

  (3) The rename() and link() operations handle two pathnames.
      But, it is not possible to know both pathnames at the moment of
      link_path_walk().

I think we need to introduce new LSM hooks outside link_path_walk().
http://kerneltrap.org/mailarchive/linux-fsdevel/2008/2/17/882024
--

[ message continues ]

But do you want to impose path-name based controls to ftruncate?
Surely once you have a file open for write (not O_APPEND), then no
other permission is required to truncate the file, is it?
If it is, then maybe the 'struct file' should be tagged at open time

Not an insolvable problem.
One could imagine an implementation where a TYPE_RENAME_FROM security
check produced a cookie that was consumed by a TYPE_RENAME_TO security
check.  The cookie could then be used by the security module to
<rant>
I suspect we would be much better off removing all the security hooks.
Security done at that level seems to be way too complex such that most
people don't really understand it.  And people who don't understand
security don't use it.
We'd be much better off getting rid of the whole "micro-manage security"
concept and provide isolation via some sort of high level container
approach.
</rant>

NeilBrown

--

[ message continues ]

Containers can be useful, but they aren't a substitute for access
control, and they don't solve the same problem.

And SELinux does get used, and recent stats on Fedora 8 suggest that few
people disable it anymore.  Advances in the SELinux tools (loadable
modules, semanage, system-config-selinux, setroubleshoot, etc) have gone
a long way to enabling users to solve problems they encounter.

-- 
Stephen Smalley
National Security Agency

--

[ message continues ]

Not only that, but containers require an LSM to provide user isolation
and root containment.

Hopefully at some point we'll be able to get around that for most VPSs,
but that's a long ways off and personally I suspect I would always want
--

[ message continues ]

You mean LSM hooks, which various LSM could utilize if desired, right?


- James
-- 
James Morris
<jmorris@namei.org>
--

[ message continues ]

Yes.

thanks,
-serge
--

[ message continues ]