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

[Christian Boltz]

Hello,

Am Mittwoch, 14. September 2011 schrieb Jamie Strandboge:
> On Tue, 2011-09-13 at 17:15 -0700, Seth Arnold wrote:
> > When I read the first proposal here, this was my exact thought; my
> > initial guess on what to do about it involved _two_ variables:
> > 
> > @{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?

> I'm not convinced about migration issues, as policy currently needs
> to be changed to use @{MYPID} -- people just have to wait until it
> is available (I could be missing something).

I'd say the migration path is needed for people who use new aa-tools 
and/or new profiles on an old kernel, and doesn't hurt too much.

Without the migration path, we'll get quite some delay because of 
dependencies - 1. push into kernel - 2. wait until major distros use 
this kernel version - 3. update parser (and profiles) - 4. wait until 
distros update to new parser and profiles.

With the migration fallback, you can remove the "wait" parts from the 
previous paragraph.

> Why are we forcing this syntax:
> @{PROC}/@{MYPID}
> 
> Instead of just:
> @{MYPID}

It's more flexible - @{MYPID} could also be used for something like 
/tmp/ssh-*/agent.@{MYPID} (that's the socket for ssh-agent, however I'm 
not sure if it's really the PID that is used)

> I also am not sure of the benefit of @{PROCSELF} since the path is
> unchanging (ie @{PROC}/self). 

I'd say @{PROCSELF} is superfluous. 
Additionally, most programs use @{PROC}/[0-9]*/, only sbin.dhclient uses 
@{PROC}/self/ according to the profiles in bzr.


Regards,

Christian Boltz
-- 
* Linux Viruscan.....
  Windows 95 found.  Remove it? (y/n)