[apparmor] [Patch 0/1] RFC: apparmor profile directory

[John Johansen]

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