[apparmor] Any plans for something like @{PROC}/@PID/ or @{PROCSELF} ?

[Seth Arnold]

On Wed, Sep 14, 2011 at 12:53 PM, John Johansen
<john.johansen at canonical.com> wrote:
> On 09/14/2011 11:56 AM, Christian Boltz wrote:

>>>> @{PIDS}=[0-9][0-9]?[0-9]?[0-9]?[0-9]?[0-9]?[0-9]?
>>>> @{MYPID}= @{PIDS} until @{__KERNEL_PID__} is available
>>
>> Sounds like a good way, but are 7-digit PIDs really used out there?

/proc/sys/kernel/pid_max makes it very easy to change the max pid, we
might as well support those installations. (Especially since the uglyness
is hidden in a variable.)

> Unlikely it sounds like a case for exposing better access to the regex
> engine.  And doing something more like the pcre re
>  [0-9]{1,7}

I wished for that feature for a second :) but it _is_ just syntactic
sugar. Time feels better spent elsewhere.

> exactly it really it has to be supported. Beyond the "wait" parts there
> are all kinds of situations where there is either a mix of old kernel
> and new policy, or new policy and old kernel.  The system state
> immediately after an upgrade is just one such case.

Good point. Should the parser "export" its own variables, reflecting
kernel capabilities?

if(__kernel_has_pid_variable__) {
	@{MYPID}=@{__KERNEL__PID__}
} else {
	@{MYPID}=@{PIDS}
}

Any variables the kernel understands can be listed in the
/sys/kernel/security/apparmor/features file; any
__kernel_has_foo_variable__ could return false by default (regardless of
'foo', to make it easily extensible), but return true when the kernel
_can_ support the tighter-integration?

(The long-awaited profile lint could report potentially mispelled
variables...)

> two further points.
> do you want the variable name capitalized?  @{MYPID} vs. @{mypid}

Hrm. I thought I wanted it capitalized, since @{HOME} feels so natural,
but we don't need our profiles to be shouty. Either way. :)

> there is also the whole issue of pid vs tid.  In some cases you want
> one, and not the other and in others you want both.

I thought about the tid too, but currently glibc doesn't export a syscall
for gettid(2), so it doesn't feel very common for a program to generate
its own tid as a filename anywhere -- it isn't as easy to get as $$ in
shell or some scripting languages.