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

Christian Boltz apparmor at cboltz.de
Sun Jul 1 11:55:25 UTC 2012


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 
;-)

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 ;-)

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.)

> 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.

> 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.

> 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.

> 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.


Regards,

Christian Boltz
-- 
After a little bit of thinking* [...]
* yes, I do it sometimes and yes, it usually hurts and leads to bad
stuff, I'll try not to do it again [Jos Poortvliet in opensuse-factory]




More information about the AppArmor mailing list