Hi John, I've been having a look at making AppArmor work with the new mount API, the basic infrastructure for which can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-context but this doesn't work for AppArmor. Unfortunately, I've come across a tricky problem that I'm not sure how to solve, but maybe you can help with. The issue involves how apparmor evaluates a DFA in do_match_mnt(). The DFA is fed the following things in the order: (1) Mountpoint path. (2) Device name. (3) File system type. (4) MS_* flags. (5) Non-binary mount data string (ie. mount options). However, what I want to do is make it so that: (1) MNT_* flags are differentiated from SB_* flags (ie. MS_* flags don't get past the syscall interface). (2) The superblock is set up as a separate step from the mounting step, prior to the mounting step and then the mounting step may be repeated multiple times for a given context, eg.; fd = fsopen("ext4"); write(fd, "d /dev/sda2"); write(fd, "o user_xattr"); write(fd, "o acl"); write(fd, "o data=ordered"); write(fd, "x create"); // We now have a superblock and we can now query fs data write(fd, "q block_size"); read(fd, query_buffer); // Mount three times fsmount(fd, "/mnt/a", MNT_NODEV | MNT_NOEXEC); fsmount(fd, "/mnt/b", 0); fsmount(fd, "/mnt/c", 0); close(fd); (3) We can pick an existing object and then create a bind mount by something like: fd = fspick("/mnt/a"); fsmount(fd, "/mnt/d"); close(fd); (4) We can reconfigure (~= remount) a superblock by picking it, setting parameters and then executing the reconfigure, eg.: fd = fspick("/mnt/a"); write(fd, "o ro"); write(fd, "x reconfigure"); close(fd); (Note that I want to use this opportunity to make reconfiguration atomic with all the parameter error checking being done first). (5) Any particular option value may exceed a page in size and the total set of options may exceed a page in size. We can do this because the options are delivered with write() and then parsed immediately. (6) Any particular option could be binary rather than text. write() is given the size of the blob, so we don't need to guess. This feature could be used to pass authentication data, say, for a network fs. So the order in which Apparmor evaluates its DFA is really inconvenient. Ideally it would be: (1) Filesystem type. (2) Device name. (3) SB_* flags. (4) Options, passed one at a time (it doesn't look like it would be a problem to save the intermediate DFA state). save this DFA state, then for each mount attempt, begin with the saved state and add: (5) Mount path. (6) MNT_* flags. I don't suppose the DFA is created such that it doesn't matter what the order is? I would really like to avoid having to buffer the entire option set as a text string just so that Apparmor can parse it for each mount (though this could be done inside Apparmor code as the fs_context struct gives the active LSM somewhere to save state). Thanks, David
