On 07/01/2012 04:55 AM, Christian Boltz wrote: > Hello, > > Am Samstag, 30. Juni 2012 schrieb John Johansen: >> Profiles are listed within a namespace directory by their sid. This is >> because a profile name can contain '/'s which are not valid >> characters in a file name. > > I'd vote for a directory name that is more human-readable than the sid > ;-) > yeah I'm not a real fan of it but its unique where just converting profile names is not
> What about using the sid + a readable profile name with non-allowed > characters replaced? > Example: > 42-bin.ping # sid 42, profile for /bin/ping > > I'd replace [^a-zA-Z0-9] with dots. This will replace some characters > that are allowed in a file name, but IMHO that's better than having > spaces etc. in the directory name which might confuse or break not-so- > well-written tools reading the directory structure. (I have a collection > of "funny filenames" - but I understand not everybody tests his programs > against something like that ;-) > it a reasonable suggestion, and easy enough to do. The only real question is where we limit to alphanum as you suggest or make it a little wider > The sid prefix will avoid any name clashes that could happen from the > character replacements. > > BTW: What exactly is a "sid"? ;-) (I'd guess it's something like an > in-kernel profile id, similar to what a pid is for a process.) > yep that is exactly what it is. Its short for security id, in apparmor it maps to a profile or unique set of profiles >> Currently the sid is output as a hex value, should this be changed to >> decimal or some other representation? > > It doesn't really matter, however decimal is already used by /proc/$pid/ > and might therefore be more common than hex. > true >> Within the profile directory the sid is not listed as a file entry >> should it be? > > In your original proposal it's superfluous, but with my proposed > modification you should add a file with the sid to avoid that someone > needs to parse the directory name. > yep >> The name and mode files list their values without an append '\n'. >> Should a trailing '\n' be added to make looking at these values from >> the cmd line cleaner. > > What's the "common way"[tm] in /proc/ and /sys/? > > Hmm, it seams there isn't something like that :-/ > cat /proc/cmdline # includes \n > cat /proc/$pid/cmdline # no \n > cat /sys/devices/cpu/$various_files # includes \n > > I tend to include the \n because without it, you'll get your prompt > mixed up if you cat the file. > I'm afraid apparmor isn't even consistent here, so of the interface files output a \n (/proc/<pid>/attr/current), while others don't. Though I think all the new ones do >> The child profiles and hats directory is currently created regardless >> of whether child profiles or hats are present. Should this directory >> only be created if the profile has children? > > For shell scripts, using "test -d" is slightly easier than testing if a > directory is empty. Besides that, it doesn't really matter. > Well its one less inode and dentry for each profile that we take from the system. Its not much but I think it would be cleaner if it wasn't there if the profile didn't have any children > > Regards, > > Christian Boltz > thanks Christian -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
