Hello. I've just returned from ELC2007 and I haven't read all posts in this thread yet, but I want to comment to this function. > In AppArmor, we are interested in pathnames relative to the namespace root. > This is the same as d_path() except for the root where the search ends. Add > a function for computing the namespace-relative path. Yes. You came to the same conclusion as TOMOYO Linux does. http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/fs/realpath.c#L39 TOMOYO Linux uses pathnames relative to the namespace root. You do this using d_path()'s way, but there needs some extensions if you want to use d_namespace_path() for access control/auditing purpose. In Linux, all characters other than NULL can be used in its pathname. This means that you can't assume that whitespaces are delimiters. For example, when you process entries in "Access ..... granted/rejected\n" format (where ..... is a pathname and \n is a carriage return, like "Access /bin/ls granted\n"), an entry "Access /bin/ls granted\nAccess /bin/cat granted\n" can be produced if ..... is "/bin/ls granted\nAccess /bin/cat". Processing such entry will produce wrong result. Also, you want wildcards (usually "*") when doing pathname comparison, but there are files that contains wildcards (for example, "/usr/share/guile/1.6/ice-9/and-let*.scm" in CentOS 4.4). You need to escape so that you can tell whether "*" indicates a literal "*" or a wildcard. Also, in non-English regions, characters that are out of ASCII printable range are included in its pathname (for example, files created via Samba from Windows client). Some programs can't handle characters that have MSB bit on, so you may want to represent all characters without using MSB bit. It may be OK if you use d_namespace_path() for processing a userland's configuration file, but it is not OK if you use it for processing a kernel's configuration file. The kernel has to be able to handle any characters. So, you may want customized version of d_namespace_path()? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
