issue with php5 abstraction in apparmor
Jamie Strandboge
jamie at canonical.com
Wed Mar 24 13:49:10 UTC 2010
On Tue, 2010-03-16 at 19:02 +0100, Nicolas Barcet wrote:
> I am pasting bellow an answer from John Johansen whom is not subscribed
> to this list.
>
> On 03/14/2010 11:36 AM, DULMANDAKH Sukhbaatar wrote:
> > As new Ubuntu LTS version is approaching I started to think about
> > > migrating my servers to it. To make future migrations smooth I started
> > > playing with Lucid and testing it. As a part of it I'm creating
> > > apparmor profile for php5-cgi. I found apparmor abstraction for php5
> > > useful, but found two problems in it. First was just easy so I fixed
> > > and filed a bug (#538661 )with patch. And last and bigger is path to
> > > php5 extensions.
>
> thanks
>
> > >
> > > php5's abstraction is allowing php5 to load its extensions from
> > > /usr/lib{64,}/php5/{libexec,extensions}/, but php5-* packages in
> > > ubuntu install extensions in /usr/lib/php5/PHP_API_VERSION or
> > > /usr/lib/php5/20090626+lfs in Lucid. so php5 cannot load extensions,
> > >
> > > I was thinking about solutions to it and found three of them. First,
> > > let's change abstraction so php5 can load extenstions from
> > > /usr/lib/php5/**. Secone one is just change path in php5 abstraction
> > > file to include PHP_API_VERSION, and make such change in every
> > > release. Last one is change php5 packaging so it'll install extension
> > > in fixed directory.
> > >
>
> fourth: use a variable to describe extension locations
> - basically the same your second solution, except the change is
> centralized to a variable.
>
> @{PHP_EXTENSIONS}=/usr/lib{64,}/php5/{libexec,extensions}/
> /usr/lib{64,}/PHP_API_VERSION
>
> I know this is already basically centralized in the include but the
> variable would allow it to be used separate from the include too.
> It also allows easy extension of the abstractions by just assigning
> a new value to it.
>
> @{PHP_EXTENSIONS}+=/some/new/path
>
> The variable gives the option of having rules that reference
> PHP_EXTENSIONS with different permissions. I am not sure how
> useful that would be atm.
>
> Another option that can be used on its own or with the variable is
> using a directory include, in the php abstraction and then dropping
> extensions to the abstraction in that dir. Basically the directory
> include will include any file in the directory, so to expand the
> abstraction you can just drop in a new file. This can aid packaging,
> as different packages can then drop relevant bits into a file owned
> by the package.
>
> When combined with the variable, it can extend the variable and thus
> all rules referencing it.
Since we are past beta now, for Lucid we should probably try to just
make the minimal change required to fix the bug. As such, I think
adjusting the abstractions to have:
/usr/lib{64,}/php5/*/*.so mr,
would be the best approach. I'd prefer to use a regex instead of '/*/'
but since the version seems to be rather free-form, this seems best.
Opinions?
--
Jamie Strandboge | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20100324/93f717f0/attachment.pgp>
More information about the ubuntu-server
mailing list