[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805020852.51125.chris.mason@oracle.com>
Date: Fri, 2 May 2008 08:52:50 -0400
From: Chris Mason <chris.mason@...cle.com>
To: Jan Engelhardt <jengelh@...ozas.de>
Cc: Jeff Mahoney <jeffm@...e.com>,
Tim Gardner <tim.gardner@...onical.com>,
jeffschroeder@...puter.org, linux-fsdevel@...r.kernel.org,
kernel-team@...ts.ubuntu.com, linux-kernel@...r.kernel.org,
linux-btrfs@...r.kernel.org, John Johansen <jjohansen@...e.de>
Subject: Re: Btrfs v0.14 Released
On Friday 02 May 2008, Jan Engelhardt wrote:
> On Thursday 2008-05-01 22:10, Jeff Mahoney wrote:
> >>>> Couldn't you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to
> >>>> work for Hardy. However the next development kernel (Intrepid) does
> >>>> not have the APPARMOR patches, so just knowing that its an UBUNTU
> >>>> kernel is not specific enough.
> >>>
> >>> I've been assuming the apparmor patches change remove_suid even when
> >>> they are not enabled in the config.
> >>
> >> Lets get Kees involved. He developed the patch set for Hardy. I would
> >> hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to
> >> its normal state.
> >
> >remove_suid() isn't the only change AppArmor makes to the VFS interface.
> >It's pretty invasive and requires that dentries are passed with a
> >companion vfsmount in most cases. Putting #ifdefs around all that code
> >would make the problem worse, not better.
>
> An alternative approach, and IMHO better suited, is to:
>
> make -C ${kdir} all I_HAZ_AN_APPARMOR=1
This is better than the current situation (oops without any clues), but I'd
prefer that people not have to know what apparmor is or if they have it.
(This isn't a knock on apparmor, I'd just rather take care of it
automagically).
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists