<snip>
+
+/*
+ * I hope these are the hokeyist lines of code in the module. Casey.
+ */
+#define DEVPTS_SUPER_MAGIC 0x1cd1
+#define SOCKFS_MAGIC 0x534F434B
+#define PIPEFS_MAGIC 0x50495045
+#define TMPFS_MAGIC 0x01021994
<snip>
+ /*
+ * This is pretty hackish.
+ * Casey says that we shouldn't have to do
+ * file system specific code, but it does help
+ * with keeping it simple.
+ */
+ switch (sbp->s_magic) {
+ case SMACK_MAGIC:
...
Rather than using the filesystem magic numbers, why not just map the
filesystem type string to a desired labeling behavior upon sb_kern_mount
and then use that behavior in d_instantiate, as is done in SELinux? For
SELinux, the mapping is maintained in policy, but naturally you could
define a fixed mapping in your module if you prefer (and in fact,
SELinux originally did that too).
Or if you are going to use the magic numbers, I think you need separate
patches to move the definitions from their current locations to
include/linux/magic.h and then #include that file in both places rather
than replicating their definitions in your code.
Another option would be to push the responsibility to the filesystems,
e.g. define some new flags for file_system_type struct that indicate the
right behavior for labeling inodes, and have the security module only
use those flags rather than needing to know about individual filesystem
types.
--
Stephen Smalley
National Security Agency
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
