Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread Chí-Thanh Christopher Nguyễn
Mike Gilbert schrieb:
 After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call no
 longer has a || die. This means that the resulting binaries may have PT_PAX,
 XATTR_PAX, both or neither markings depending on kernel configuration,
 filesystem and mount options.

 I'd say that is not a good thing. If you agree with me, what could be done
 here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
 would probably require pax-mark calls to be conditional on pax_kernel USE
 flag or similar.

 Most ebuilds do not call pax-mark || die. Most people do not run PaX
 systems, so a failure here is not a major issue.

I agree that not having the pax-mark is not a significant problem
currently. It could become one when PaX becomes more widespread, but
that is not likely in the near term.

What I think is bad is the automagic aspect of enabling pax-mark.


Best regards,
Chí-Thanh Christopher Nguyễn




Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread Rafael Goncalves Martins
On Mon, Apr 8, 2013 at 9:29 AM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Mike Gilbert schrieb:
 After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call 
 no
 longer has a || die. This means that the resulting binaries may have PT_PAX,
 XATTR_PAX, both or neither markings depending on kernel configuration,
 filesystem and mount options.

 I'd say that is not a good thing. If you agree with me, what could be done
 here? Have pax-mark die in the eclass or mandate || die in ebuilds? This
 would probably require pax-mark calls to be conditional on pax_kernel USE
 flag or similar.

 Most ebuilds do not call pax-mark || die. Most people do not run PaX
 systems, so a failure here is not a major issue.

 I agree that not having the pax-mark is not a significant problem
 currently. It could become one when PaX becomes more widespread, but
 that is not likely in the near term.

 What I think is bad is the automagic aspect of enabling pax-mark.


 Best regards,
 Chí-Thanh Christopher Nguyễn



I had some issues with pax-mark failling to work on openvz containers
stored on partitions mounted without the user_xattr argument and
ebuilds with '|| die', and was going to open bugs to people remove the
'|| die' statements from the ebuilds, when I saw this thread.

Disable xattr isn't a very common use case, but it is still valid. I
don't want to have my builds falling at install phase just because the
binary can't be pax-mark'ed, when I clearly don't care about PaX.

If we don't want the automagic behavior, we should allow users to
explicitly disable it.

--
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/



Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread Michael Haubenwallner

On 04/08/2013 12:08 AM, Anthony G. Basile wrote:
 On 04/07/2013 05:20 PM, Mike Gilbert wrote:
 On Sun, Apr 7, 2013 at 5:11 PM, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Hello All,

 After recent changes in dev-lang/v8 and related ebuilds, the pax-mark call 
 no
 longer has a || die. This means that the resulting binaries may have PT_PAX,
 XATTR_PAX, both or neither markings depending on kernel configuration,
 filesystem and mount options.

Although not used to PaX in general, I've fixed a bug report[1] where pax-mark 
-c was
sufficient to get some prebuilt thirt-party binary to run on user's hardened 
machine.

 In the mean time, maybe we could disable XATTR_PAX markings by default
 for people not using the hardened profile.

 You can disable either or both type of pax markings by setting PAX_MARKINGS.
 We can change the default in the eclass.  Its currently set to PT XT.
 Setting it to PT would revert to only doing PT_PAX markings.
 Then users will have to manually set XT in their make.conf.

While fixing that bug I've discovered the default value of PAX_MARKINGS=PT
(has changed to PT XT since), but no profile actually setting 
PAX_MARKINGS=none.

Actually I've wondered if it would make more sense to default to 
PAX_MARKINGS=none,
and have the hardened profiles (or the user in make.conf) set a different value.

But thinking again now, I'm wondering if pax-mark should be done in pkg_preinst 
rather
than src_install - for the sake of binary merges when the build machine has 
different
PAX_MARKINGS than the target machine (no idea if that ever would happen).

[1] https://bugs.gentoo.org/show_bug.cgi?id=456694

my 2 cents
/haubi/



Re: [gentoo-dev] Automagic pax-mark

2013-04-08 Thread Mike Gilbert
On Mon, Apr 8, 2013 at 10:21 AM, Michael Haubenwallner ha...@gentoo.org wrote:
 Actually I've wondered if it would make more sense to default to 
 PAX_MARKINGS=none,
 and have the hardened profiles (or the user in make.conf) set a different 
 value.

That makes some sense to me. The downside is that that switching from
vanilla gentoo to hardened would require a rebuild of all packages
that need pax markings.

 But thinking again now, I'm wondering if pax-mark should be done in 
 pkg_preinst rather
 than src_install - for the sake of binary merges when the build machine has 
 different
 PAX_MARKINGS than the target machine (no idea if that ever would happen).

This also makes sense to me.