[apparmor] [patch] split off apache permissions to abstractions/apache2-common

[Christian Boltz]

Hello,

Am Donnerstag, 5. Januar 2012 schrieb Steve Beattie:
> On Thu, Jan 05, 2012 at 09:02:22PM +0100, Christian Boltz wrote:
> > Am Mittwoch, 4. Januar 2012 schrieb Steve Beattie:
> > > On Thu, Dec 22, 2011 at 01:17:57AM +0100, Christian Boltz wrote:

> > My patch changes this to /**/.htaccess, which means:
> >                        current profile   
> >                        with my patch
> > 
> > /.htaccess               allowed [1]         denied
> > /some/.htaccess          allowed             allowed
> > /some/where/.htaccess    allowed             allowed
> > /foo/some.htaccess       allowed [2]         denied
> > 
> > In other words:
> > [1] a .htaccess in / is no longer allowed
> > [2] the (IMHO accidential) permissions for files named *.htaccess
> > are> 
> >     also dropped.
> > 
> > Even if it is unlikely that someone needs /.htaccess or
> > *.htaccess,
> > I'm afraid there will be at least one person who relies on one of
> > them. To make it even worse, if a /.htaccess exists and access is
> > denied, it will break the whole server :-/ (see my reply to John
> > for details)

> I really did understand that you were proposing to drop access to both
> case [1] and case [2]. Case [2] seems to be an unintended oversight
> and I'd really like to fix it.

OK, agreed - case [2] counts as bugfix.

> I do grant that preventing access to /.htaccess and having the server
> break because of it is less than ideal. But if you've configured
> your server such that it uses /.htaccess, you'll need to adjust your
> profile either when upgrading to the 2.8[0] release or possibly in
> 2.7.1, depending on what we choose here.

The difference is in the psychology of version numbers ;-)
Minor version updates should always be a drop-in replacement that 
shouldn't break anything.

Or to explain it less verbose:
- if we change it in 2.7.1, it's a regression
- if we change it in 2.8, then it's "just" a change
;-)

> I'll also point out that apache allows one to use a different name
> for the .htaccess files with the Accessfilename directive (see
> http://httpd.apache.org/docs/2.2/mod/core.html#accessfilename ).
> So I suppose it's possible that someone choose an alternate name that
> happened to match the pattern (e.g. some.htaccess), which would then
> break with this bugfix.

Yes, but that sounds even more exotic to me than using /.htaccess ;-)

> That said, it seems unlikely that people configure apache in either
> way. (Where performance is a concern, upstream recommends not using
> .htaccess at all, but instead adjusting the apache configuration
> directly.)

Yes, or at least allow .htaccess files only in the docroot and not in 
the directories above - that's the best you can get if you need to allow 
.htaccess files and still are interested in performance.

> > b) drop only [2] (it looks like a bug that this was allowed, and
> >    denying it at least can't break the whole server). The patch 
> >    would then be:
> > - /**.htaccess r,
> > + /.htaccess r, # warning: .htaccess directly in / will be
> > disallowed +               # in future versions (.htaccess in
> > subdirectories is +               # and will stay allowed by
> > abstractions/apache2-common)
> > 
> > Which solution do you like more?
> 
> Of these two choices, I'd personally prefer (b). 

OK, then I'll commit this one to the 2.7 branch.

> We should probably highlight this in the release notes as well.

Yes, good idea.

> > > >    # Apache
> > > >    network inet stream,
> > > > +  network inet6 stream,
> > > 
> > > I'm actually surprised this is needed given the inclusion of
> > > abstractions/nameservice
> > 
> > That's the result of using vi to merge the profiles (did I already
> > mention that a merge tool would be helpful? ;-)

> I'm okay with having it in apache2-common to make it explicit. It was
> more an expression of surprise that it showed up (I was more fearful
> of it being the result of another logprof/genprof bug).

;-)

> > At least on an "old" server with openSUSE 11.1 / AppArmor 2.3
> > HANDLING_UNTRUSTED_INPUT seems to fail to switch to the correct
> > hat in some cases. Not often, but on a busy server, it sums up to
> > some requests per day.

> No, there's not been any changes in mod_apparmor that would affect
> this.  That said, I've not seen this occur on Ubuntu with newer
> versions of apache, so it's possible there was something fixed within
> apache that affected this behavior. 

Let's hope that you are right ;-)


Regards,

Christian Boltz
-- 
> Es steht dir frei, dich auch auszutragen, damit du von Idioten wie
> David, Thorsten, Bernd, ... nicht weiter belästigt wirst.
Und ich gehöre da nicht mehr dazu?
[> Matthias Houdek und Florian Gross in suse-linux]