[gentoo-dev] [rfc] enable USE=xattr by default

[gentoo-dev] [rfc] enable USE=xattr by default

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

USE=xattr is needed nowadays to support:
- filesystem caps (those things that let you drop set*id and generally
  improves system security w/little to no runtime overhead)
- PaX file markings (replaces binutils ELF markings)
- selinux

we actually have USE=filecaps on by default already, and catalyst
hard requires tar[xattr] in order to work.  the hardened profile
also package.use.force's this flag on for some core packages.

not too many packages actually utilize this flag, and when they do,
it's to pull in the attr package which clocks in at <200 KiB.  the
runtime overhead tends to be low to non-existent as xattrs tend to
be used only when requested.

when support is not available in the FS or kernel, packages should
generally fall back gracefully.

anyone opposed to flipping this flag on by default ?

reference:
https://bugs.gentoo.org/506198
https://bugs.gentoo.org/556408
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Wed, Oct 14, 2015 at 11:48:07PM -0400, Mike Frysinger wrote:
> USE=xattr is needed nowadays to support:
> - filesystem caps (those things that let you drop set*id and generally
>   improves system security w/little to no runtime overhead)
> - PaX file markings (replaces binutils ELF markings)
> - selinux
> 
> we actually have USE=filecaps on by default already, and catalyst
> hard requires tar[xattr] in order to work.  the hardened profile
> also package.use.force's this flag on for some core packages.
> 
> not too many packages actually utilize this flag, and when they do,
> it's to pull in the attr package which clocks in at <200 KiB.  the
> runtime overhead tends to be low to non-existent as xattrs tend to
> be used only when requested.
> 
> when support is not available in the FS or kernel, packages should
> generally fall back gracefully.
> 
> anyone opposed to flipping this flag on by default ?
> 
> reference:
> https://bugs.gentoo.org/506198
> https://bugs.gentoo.org/556408
> -mike

As part of the hardened and SELinux teams, definitely +1 from me.

-- Jason

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Tobias Klausmann]

Hi! 

On Wed, 14 Oct 2015, Mike Frysinger wrote:
> anyone opposed to flipping this flag on by default ?
> 
> reference:
> https://bugs.gentoo.org/506198
> https://bugs.gentoo.org/556408

No objection, but a bit of a datapoint. I use btrfs on one of my
machines, and that filesystem (apparently) does not support
XATTR_PAX markings. So on every update I get some packages with
message like these:

>>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 on 20151013-150646 CEST:

LOG: install
Failed to set XATTR_PAX markings -me qemu-system-aarch64.
Failed to set XATTR_PAX markings -me qemu-system-alpha.
Failed to set XATTR_PAX markings -me qemu-system-i386.
Failed to set XATTR_PAX markings -me qemu-system-x86_64.
Failed to set XATTR_PAX markings -me qemu-aarch64.
Failed to set XATTR_PAX markings -me qemu-alpha.
Failed to set XATTR_PAX markings -me qemu-i386.
Failed to set XATTR_PAX markings -me qemu-x86_64.

Two things about this: the message is not really useful, unless I
know what -me does. Also, I never requested anything PaX-ish, I
just don't want to to have SUID binaries when I can avoid it.

By now the messages are just an annoyance/spam to me, but I
suspect this may be more of a problem for people who have lower
pain thresholds.

Regards,
Tobias

-- 
"Sendmail is the sort of tool that gave UNIX its bad reputation."
   -- _System Performance Tuning_

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Tobias Klausmann posted on Thu, 15 Oct 2015 10:57:45 +0200 as excerpted:

> By now the messages are just an annoyance/spam to me, but I suspect this
> may be more of a problem for people who have lower pain thresholds.

That could have been my post... all the way down to and including the 
annoyance/spam bit.  Tho I hadn't thought of it as a btrfs thing, but 
yes, I'm running it too.

Can't those messages be turned off, if, say, the kernel doesn't support 
pax, or if btrfs-progs is installed, or something?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 6:32 AM, Duncan wrote:
> Tobias Klausmann posted on Thu, 15 Oct 2015 10:57:45 +0200 as excerpted:
>
>> By now the messages are just an annoyance/spam to me, but I suspect this
>> may be more of a problem for people who have lower pain thresholds.
> That could have been my post... all the way down to and including the
> annoyance/spam bit.  Tho I hadn't thought of it as a btrfs thing, but
> yes, I'm running it too.
>
> Can't those messages be turned off, if, say, the kernel doesn't support
> pax, or if btrfs-progs is installed, or something?
>
yes we can silence those. but that there's still the issue that xattrs 
on btrfs should not be a problem.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
> Hi! 
> 
> On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > anyone opposed to flipping this flag on by default ?
> > 
> > reference:
> > https://bugs.gentoo.org/506198
> > https://bugs.gentoo.org/556408
> 
> No objection, but a bit of a datapoint. I use btrfs on one of my
> machines, and that filesystem (apparently) does not support
> XATTR_PAX markings. So on every update I get some packages with
> message like these:

I used to run hardened on btrfs and it worked fine. pax xattrs are in
the user namespace (user.pax.flags) which isnt protected (unlike eg.
security.*). I dont remember doing anything special to enable xattrs on
btrfs, most of the newer FSs have them enabled by default.

Can you try this:

# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
user.pax.flags="me"
user.test="foo"

If this works then something else is causing those messages and we
should look into it further.

> 
> >>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 on 20151013-150646 CEST:
> 
> LOG: install
> Failed to set XATTR_PAX markings -me qemu-system-aarch64.
> Failed to set XATTR_PAX markings -me qemu-system-alpha.
> Failed to set XATTR_PAX markings -me qemu-system-i386.
> Failed to set XATTR_PAX markings -me qemu-system-x86_64.
> Failed to set XATTR_PAX markings -me qemu-aarch64.
> Failed to set XATTR_PAX markings -me qemu-alpha.
> Failed to set XATTR_PAX markings -me qemu-i386.
> Failed to set XATTR_PAX markings -me qemu-x86_64.
> 
> Two things about this: the message is not really useful, unless I
> know what -me does. Also, I never requested anything PaX-ish, I
> just don't want to to have SUID binaries when I can avoid it.

Not that it matters since you dont run hardened, but "m" means "disable
mprotext" and "e" means "disable trampoline emulation".

-- Jason
> 
> By now the messages are just an annoyance/spam to me, but I
> suspect this may be more of a problem for people who have lower
> pain thresholds.
> 
> Regards,
> Tobias
> 
> -- 
> "Sendmail is the sort of tool that gave UNIX its bad reputation."
>    -- _System Performance Tuning_
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 18:56:28 +0800
Jason Zaman <perfinion@gentoo.org> wrote:

> On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
> > Hi! 
> > 
> > On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > > anyone opposed to flipping this flag on by default ?
> > > 
> > > reference:
> > > https://bugs.gentoo.org/506198
> > > https://bugs.gentoo.org/556408
> > 
> > No objection, but a bit of a datapoint. I use btrfs on one of my
> > machines, and that filesystem (apparently) does not support
> > XATTR_PAX markings. So on every update I get some packages with
> > message like these:
> 
> I used to run hardened on btrfs and it worked fine. pax xattrs are in
> the user namespace (user.pax.flags) which isnt protected (unlike eg.
> security.*). I dont remember doing anything special to enable xattrs
> on btrfs, most of the newer FSs have them enabled by default.
> 
> Can you try this:
> 
> # getfattr -d -m- /bin/ping

I think he should check xattr support in PORTAGE_TMPDIR in the first
place. :) I suspect something like tmpfs mounted on it
(and CONFIG_TMPFS_XATTR=n in the kernel config).

-- 
Alexander Tsoy

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Alexander Tsoy posted on Thu, 15 Oct 2015 14:09:29 +0300 as excerpted:

> On Thu, 15 Oct 2015 18:56:28 +0800 Jason Zaman <perfinion@gentoo.org>
> wrote:
> 
>> On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
>> > Hi!
>> > 
>> > On Wed, 14 Oct 2015, Mike Frysinger wrote:
>> > > anyone opposed to flipping this flag on by default ?
>> > > 
>> > > reference:
>> > > https://bugs.gentoo.org/506198 https://bugs.gentoo.org/556408
>> > 
>> > No objection, but a bit of a datapoint. I use btrfs on one of my
>> > machines, and that filesystem (apparently) does not support XATTR_PAX
>> > markings. So on every update I get some packages with message like
>> > these:
>> 
>> I used to run hardened on btrfs and it worked fine. pax xattrs are in
>> the user namespace (user.pax.flags) which isnt protected (unlike eg.
>> security.*). I dont remember doing anything special to enable xattrs on
>> btrfs, most of the newer FSs have them enabled by default.
>> 
>> Can you try this:
>> 
>> # getfattr -d -m- /bin/ping
> 
> I think he should check xattr support in PORTAGE_TMPDIR in the first
> place. :) I suspect something like tmpfs mounted on it (and
> CONFIG_TMPFS_XATTR=n in the kernel config).

As I posted, I have the same problem here (tho I didn't blame btrfs), but 
while PORTAGE_TMPDIR is indeed tmpfs, zgrep XATTR /proc/config.gz says 
CONFIG_TMPFS_XATTR=y, so that's not it.

But the closest thing btrfs has to that option is 
CONFIG_BTRFS_FS_POSIX_ACL, which I do NOT have enabled, so if it's 
required...

Meanwhile, the setfattr/getfattr test works (tho getfattr says it's 
removing the leading /).  So it would appear btrfs is fine, and the tmpfs 
PORTAGE_TMPDIR is fine, but I still get those XATTR_PAX failed-to-set 
warnings.

Tho I just remerged iputils and didn't get the warnings, so maybe we're 
not checking the right binaries?

IIRC, firefox gave me the warnings, however, and I'm doing an update 
including 41.0.1 ATM, so I can verify, tho of course FF takes awhile to 
build and it's near the end of a list of 100+ packages to update, so...

Could it be related to one of FEATURES="ipc-sandbox sandbox userpriv 
usersandbox xattr" (choosing a few from my set that look like possible 
candidates)?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Tobias Klausmann]

Hi! 

On Thu, 15 Oct 2015, Jason Zaman wrote:
> Can you try this:
> 
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> # setfattr -n user.test -v "foo" ./ping
> # setfattr -n user.pax.flags -v "me" ./ping
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> user.pax.flags="me"
> user.test="foo"
> 
> If this works then something else is causing those messages and we
> should look into it further.

# cd /bin/
# getfattr -d -m- ./ping
# file: ping
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=

# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- ./ping
# file: ping
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
user.pax.flags="me"
user.test="foo"

But note that emerging iputils does _not_ result in the PaX
messages I described. Here's an incomplete list of packages that
have triggered them in the past:

app-emulation/qemu-2.4.0.1
dev-lang/ghc-7.10.2-r1
dev-lang/python-3.5.0-r1
media-video/mpv-0.11.0
sys-devel/llvm-3.7.0-r2
www-client/firefox-bin-41.0.1
www-client/google-chrome-beta-46.0.2490.64_p1

I have no clue what they do differently from iputils to result in
those messages.

So I looked at a file mentioned during the llvm merge,
/usr/bin/llvm-rtdyld:

# getfattr ./llvm-rtdyld 
# setfattr -n user.test -v "foo" ./llvm-rtdyld
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld
# getfattr -d -m- ./llvm-rtdyld

Then I remembered that the setfattr might not happen in the live
system, but on the tmpfs mounted on /var/tmp/portage.

So I tried it there:

# cp ./llvm-rtdyld /var/tmp/portage
# cd /var/tmp/portage
# getfattr -d -m- ./llvm-rtdyld
# setfattr -n user.test -v "foo" ./llvm-rtdyld
setfattr: ./llvm-rtdyld: Operation not supported
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld
setfattr: ./llvm-rtdyld: Operation not supported

So it's not a BTRFS problem, but one of tmpfs. So I wondered if I
maybe had missed to activate xattr suport for tmpfs, but no:

# zgrep -i tmpfs /proc/config.gz 
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
#

I have no clue what's missing, since I can't find a mount option
or anything that I might have missed:

# mount -l -t tmpfs |grep portage
none on /var/tmp/portage type tmpfs (rw,relatime,size=8388608k)

On a whim, I tried user_xattr, something older ext* FSs support,
but alas:

# mount -o remount,user_xattr /var/tmp/portage
mount: /var/tmp/portage not mounted or bad option

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
# dmesg|tail -n1
[ 8623.541053] tmpfs: No value for mount option 'user_xattr'

Providing =something just results in this:
[ 8701.215926] tmpfs: Bad mount option user_xattr

So I'm fresh out of ideas.

Regards,
Tobias





-- 
"Sendmail is the sort of tool that gave UNIX its bad reputation."
   -- _System Performance Tuning_

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 7:22 AM, Tobias Klausmann <klausman@gentoo.org> wrote:
>
> So it's not a BTRFS problem, but one of tmpfs. So I wondered if I
> maybe had missed to activate xattr suport for tmpfs, but no:
>
> # zgrep -i tmpfs /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_TMPFS=y
> CONFIG_TMPFS_POSIX_ACL=y
> CONFIG_TMPFS_XATTR=y
> #

Same here (but I don't enable DEVTMPFS_MOUNT).  I had also wondered if
this was btrfs-related but it might indeed be tmpfs related.

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman <perfinion@gentoo.org> wrote:
>
> Can you try this:
>
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> # setfattr -n user.test -v "foo" ./ping
> # setfattr -n user.pax.flags -v "me" ./ping
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> user.pax.flags="me"
> user.test="foo"
>
> If this works then something else is causing those messages and we
> should look into it further.

This behaves exactly as described above for me on btrfs, but I still
do get all the error messages whenever I install stuff.

I assume the extra attributes are harmless and will get removed the
next time I update ping?

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 7:24 AM, Rich Freeman wrote:
> On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman <perfinion@gentoo.org> wrote:
>> Can you try this:
>>
>> # getfattr -d -m- /bin/ping
>> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
>> # setfattr -n user.test -v "foo" ./ping
>> # setfattr -n user.pax.flags -v "me" ./ping
>> # getfattr -d -m- /bin/ping
>> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
>> user.pax.flags="me"
>> user.test="foo"
>>
>> If this works then something else is causing those messages and we
>> should look into it further.
> This behaves exactly as described above for me on btrfs, but I still
> do get all the error messages whenever I install stuff.
>
> I assume the extra attributes are harmless and will get removed the
> next time I update ping?
>
okay its good to know that that this does work.  something might be 
misconfigured on tobias's box.

let me know any problems with XATTR_PAX markings because that's going to 
become the default soon and in the near future the only option once we 
drop the PT_PAX patch from binutils.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> On 10/15/15 7:24 AM, Rich Freeman wrote:
> > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman <perfinion@gentoo.org> wrote:
> >> Can you try this:
> >>
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> >> # setfattr -n user.test -v "foo" ./ping
> >> # setfattr -n user.pax.flags -v "me" ./ping
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> >> user.pax.flags="me"
> >> user.test="foo"
> >>
> >> If this works then something else is causing those messages and we
> >> should look into it further.
> > This behaves exactly as described above for me on btrfs, but I still
> > do get all the error messages whenever I install stuff.
> >
> > I assume the extra attributes are harmless and will get removed the
> > next time I update ping?
> >
> okay its good to know that that this does work.  something might be 
> misconfigured on tobias's box.
> 
> let me know any problems with XATTR_PAX markings because that's going to 
> become the default soon and in the near future the only option once we 
> drop the PT_PAX patch from binutils.

I seem to recall something about PaX enabling user.* xattrs on tmpfs and
mainline kernel supports only security.* on tmpfs. Could that be the
cause? If that is the case then what do we do about everyone that is
using gentoo-sources? It probably doesnt matter so just silencing the
errors is probably enough.

-- Jason
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail    : blueness@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 19:47:59 +0800
Jason Zaman <perfinion@gentoo.org> wrote:

> On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> > On 10/15/15 7:24 AM, Rich Freeman wrote:
> > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman
> > > <perfinion@gentoo.org> wrote:
> > >> Can you try this:
> > >>
> > >> # getfattr -d -m- /bin/ping
> > >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> > >> # setfattr -n user.test -v "foo" ./ping
> > >> # setfattr -n user.pax.flags -v "me" ./ping
> > >> # getfattr -d -m- /bin/ping
> > >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> > >> user.pax.flags="me"
> > >> user.test="foo"
> > >>
> > >> If this works then something else is causing those messages and
> > >> we should look into it further.
> > > This behaves exactly as described above for me on btrfs, but I
> > > still do get all the error messages whenever I install stuff.
> > >
> > > I assume the extra attributes are harmless and will get removed
> > > the next time I update ping?
> > >
> > okay its good to know that that this does work.  something might be 
> > misconfigured on tobias's box.
> > 
> > let me know any problems with XATTR_PAX markings because that's
> > going to become the default soon and in the near future the only
> > option once we drop the PT_PAX patch from binutils.
> 
> I seem to recall something about PaX enabling user.* xattrs on tmpfs
> and mainline kernel supports only security.* on tmpfs. Could that be
> the cause? If that is the case then what do we do about everyone that
> is using gentoo-sources? It probably doesnt matter so just silencing
> the errors is probably enough.
> 

I was wrong. This patch was not merged upstream. It is still needed and
included in latest genpatches for 4.2:

$ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
./1500_XATTR_USER_PREFIX.patch

-- 
Alexander Tsoy

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 14:58:01 +0300
Alexander Tsoy <alexander@tsoy.me> wrote:

> On Thu, 15 Oct 2015 19:47:59 +0800
> Jason Zaman <perfinion@gentoo.org> wrote:
> 
> > On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> > > On 10/15/15 7:24 AM, Rich Freeman wrote:
> > > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman
> > > > <perfinion@gentoo.org> wrote:
> > > >> Can you try this:
> > > >>
> > > >> # getfattr -d -m- /bin/ping
> > > >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> > > >> # setfattr -n user.test -v "foo" ./ping
> > > >> # setfattr -n user.pax.flags -v "me" ./ping
> > > >> # getfattr -d -m- /bin/ping
> > > >> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA=
> > > >> user.pax.flags="me"
> > > >> user.test="foo"
> > > >>
> > > >> If this works then something else is causing those messages and
> > > >> we should look into it further.
> > > > This behaves exactly as described above for me on btrfs, but I
> > > > still do get all the error messages whenever I install stuff.
> > > >
> > > > I assume the extra attributes are harmless and will get removed
> > > > the next time I update ping?
> > > >
> > > okay its good to know that that this does work.  something might
> > > be misconfigured on tobias's box.
> > > 
> > > let me know any problems with XATTR_PAX markings because that's
> > > going to become the default soon and in the near future the only
> > > option once we drop the PT_PAX patch from binutils.
> > 
> > I seem to recall something about PaX enabling user.* xattrs on tmpfs
> > and mainline kernel supports only security.* on tmpfs. Could that be
> > the cause? If that is the case then what do we do about everyone
> > that is using gentoo-sources? It probably doesnt matter so just
> > silencing the errors is probably enough.
> > 
> 
> I was wrong. This patch was not merged upstream. It is still needed
> and included in latest genpatches for 4.2:
> 
> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
> ./1500_XATTR_USER_PREFIX.patch
> 

Oops.. Sorry, I replied on the wrong message. This was intended for
Tobias.

-- 
Alexander Tsoy

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy <alexander@tsoy.me> wrote:
>
> I was wrong. This patch was not merged upstream. It is still needed and
> included in latest genpatches for 4.2:
>
> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
> ./1500_XATTR_USER_PREFIX.patch

I suspect what we all have in common then is that we're using tmpfs to
do builds and we're not using genpatches.

If the warning isn't an issue for non-hardened users then I don't see
any need to change anything.  Is the patch (or something similar)
likely to get merged?  It doesn't really seem ideal to be dependent on
something not in mainline.

-- 
Rich

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Rich Freeman posted on Thu, 15 Oct 2015 08:36:59 -0400 as excerpted:

> On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy <alexander@tsoy.me>
> wrote:
>>
>> I was wrong. This patch was not merged upstream. It is still needed and
>> included in latest genpatches for 4.2:
>>
>> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
>> ./1500_XATTR_USER_PREFIX.patch
> 
> I suspect what we all have in common then is that we're using tmpfs to
> do builds and we're not using genpatches.
> 
> If the warning isn't an issue for non-hardened users then I don't see
> any need to change anything.  Is the patch (or something similar)
> likely to get merged?  It doesn't really seem ideal to be dependent on
> something not in mainline.

Having just completed an update and checked the warnings, which occurred 
on firefox and llvm, I can confirm that the paths mentioned in the 
warnings are in the tmpfs PORTAGE_TMPDIR, *not* on btrfs.

And I run a mainline (direct git, in fact) kernel.

So the problem does indeed appear to be PORTAGE_TMPDIR on tmpfs, on a 
kernel without the gentoo patches.

AFAIK pax markings only matter if pax is enabled, which it won't be on 
mainline kernels since I don't believe they include the pax patches.  So 
the warnings, while annoying, don't signify a real problem.

But it would definitely be nice to have them turned off, or even have the 
entire attempt to do pax markings in the first place turned off, on non-
hardened kernels.

In any case, doesn't seem to be btrfs related at all. False alarm there. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[netfab]

Le 15/10/15 à 15:11, Duncan a tapoté :
> Having just completed an update and checked the warnings, which
> occurred on firefox and llvm, I can confirm that the paths mentioned
> in the warnings are in the tmpfs PORTAGE_TMPDIR, *not* on btrfs.
> 
> And I run a mainline (direct git, in fact) kernel.
> 
> So the problem does indeed appear to be PORTAGE_TMPDIR on tmpfs, on a 
> kernel without the gentoo patches.

I'm in the same situation, i.e. latest longterm kernel from direct git
and building packages on tmpfs, and since a few months I'm finding in
logs these kinds of warnings for many packages :
> Failed to set XATTR_PAX markings -me ...

Le 15/10/15 à 15:11, Duncan a tapoté :
> But it would definitely be nice to have them turned off, or even have
> the entire attempt to do pax markings in the first place turned off,
> on non- hardened kernels.

Is there a bug opened about this ?
If the gentoo kernel XATTR patch is really required, it would be great
if users who do not use a gentoo kernel were aware about this. Does
PAX_MARKINGS="none" in make.conf (see pax-utils.eclass) is the way to
go ? Also this problem has already been discussed on @gentoo-user ¹.

1. http://www.gossamer-threads.com/lists/gentoo/user/305478

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/16/15 3:14 AM, netfab wrote:
> Le 15/10/15 à 15:11, Duncan a tapoté :
>
> Is there a bug opened about this ?
> If the gentoo kernel XATTR patch is really required, it would be great
> if users who do not use a gentoo kernel were aware about this. Does
> PAX_MARKINGS="none" in make.conf (see pax-utils.eclass) is the way to
> go ? Also this problem has already been discussed on @gentoo-user ¹.
>
> 1. http://www.gossamer-threads.com/lists/gentoo/user/305478
>
I'm thinking that I should silence those warnings when we have 
PAX_MARKINGS="" or PAX_MARKINGS unset in the make.conf file.  Users who 
want either PT or XT pax markings need to know about failures, but users 
that don't care don't need to see anything.

We should make clear that pax markings are only supported on either 
gentoo-sources or hardened-sources because those kernels carry the patch 
which allow xattrs in the user.pax.* namespace on tmpfs.  So if a users 
emerges while running a gentoo-sources kernel and then boots into a 
hardened-sources kernel, they'll get the correct pax markings.  In fact, 
you can switch back and forth between gentoo-sources and 
hardened-sources all you like and the pax markings will be preserved.  
But if you emerge when using a vanilla kernel or some other which 
doesn't support user.pax.* on tmpfs, then you'll loose those markings.  
Booting afterwards into a hardened-sources kernel will leave pkgs which 
require pax markings broken.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Peter Stuge]

Anthony G. Basile wrote:
> if you emerge when using a vanilla kernel or some other which doesn't
> support user.pax.* on tmpfs, then you'll loose those markings.

Would it be at all possible to add the markings after/as files land
on the destination filesystem instead?

It's not really intuitive that tmpfs on the emerging kernel must
support a feature at build-time which is used by the runtime kernel
at run-time..


And what about stages? tar saves all attributes? It's a bit weak to
be less flexible than that.


Thanks

//Peter

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/16/15 7:49 PM, Peter Stuge wrote:
> Anthony G. Basile wrote:
>> if you emerge when using a vanilla kernel or some other which doesn't
>> support user.pax.* on tmpfs, then you'll loose those markings.
> Would it be at all possible to add the markings after/as files land
> on the destination filesystem instead?
first, I overspoke.  that line should read "you might loose those markings".

since we sometimes have to do pax markings during src_compile() or 
src_test() or early during src_install() etc, the safest approach is to 
preserve xattrs at every step of the process.  so we wrote a wrapper on 
install for that and made sure portage provided end-to-end xattr 
support.  this doesn't prevent an ebuild from also doing the markings 
again during pkg_postinst() after the file(s) lands just in case.

>
> It's not really intuitive that tmpfs on the emerging kernel must
> support a feature at build-time which is used by the runtime kernel
> at run-time..
>
>
> And what about stages? tar saves all attributes? It's a bit weak to
> be less flexible than that.

we made sure catalyst will preserve xattrs when bundling.

>
>
> Thanks
>
> //Peter
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Peter Stuge]

Anthony G. Basile wrote:
>> Would it be at all possible to add the markings after/as files land
>> on the destination filesystem instead?
..
> since we sometimes have to do pax markings during src_compile() or 
> src_test() or early during src_install() etc, the safest approach is to 
> preserve xattrs at every step of the process.  so we wrote a wrapper on 
> install for that and made sure portage provided end-to-end xattr support.  
> this doesn't prevent an ebuild from also doing the markings again during 
> pkg_postinst() after the file(s) lands just in case.

I guess I'm suggesting to do so automatically, if markings were added
(maybe only when unsuccessfully) in any of the previous steps,
presumably involving tmpfs.


>> It's not really intuitive that tmpfs on the emerging kernel must
>> support a feature at build-time which is used by the runtime kernel
>> at run-time..
>>
>> And what about stages? tar saves all attributes? It's a bit weak to
>> be less flexible than that.
>
> we made sure catalyst will preserve xattrs when bundling.

Cool - but! It all only works reliably if the build host runs a
patched kernel, since it wraps portage, correct? Not as cool.


//Peter

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Mike Gilbert]

On Thu, Oct 15, 2015 at 8:36 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy <alexander@tsoy.me> wrote:
>>
>> I was wrong. This patch was not merged upstream. It is still needed and
>> included in latest genpatches for 4.2:
>>
>> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
>> ./1500_XATTR_USER_PREFIX.patch
>
> I suspect what we all have in common then is that we're using tmpfs to
> do builds and we're not using genpatches.
>
> If the warning isn't an issue for non-hardened users then I don't see
> any need to change anything.  Is the patch (or something similar)
> likely to get merged?  It doesn't really seem ideal to be dependent on
> something not in mainline.

Indeed. I would suggest we at least disable XT PaX markings in the
base profile until this gets merged in the mainline kernel.

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 4:57 AM, Tobias Klausmann wrote:
> Hi!
>
> On Wed, 14 Oct 2015, Mike Frysinger wrote:
>> anyone opposed to flipping this flag on by default ?
>>
>> reference:
>> https://bugs.gentoo.org/506198
>> https://bugs.gentoo.org/556408
> No objection, but a bit of a datapoint. I use btrfs on one of my
> machines, and that filesystem (apparently) does not support
> XATTR_PAX markings. So on every update I get some packages with
> message like these:
>
>>>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 on 20151013-150646 CEST:
> LOG: install
> Failed to set XATTR_PAX markings -me qemu-system-aarch64.
> Failed to set XATTR_PAX markings -me qemu-system-alpha.
> Failed to set XATTR_PAX markings -me qemu-system-i386.
> Failed to set XATTR_PAX markings -me qemu-system-x86_64.
> Failed to set XATTR_PAX markings -me qemu-aarch64.
> Failed to set XATTR_PAX markings -me qemu-alpha.
> Failed to set XATTR_PAX markings -me qemu-i386.
> Failed to set XATTR_PAX markings -me qemu-x86_64.
>
> Two things about this: the message is not really useful, unless I
> know what -me does. Also, I never requested anything PaX-ish, I
> just don't want to to have SUID binaries when I can avoid it.
>
> By now the messages are just an annoyance/spam to me, but I
> suspect this may be more of a problem for people who have lower
> pain thresholds.
>
> Regards,
> Tobias
>
open a bug because this should work on btrfs.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/14/15 11:48 PM, Mike Frysinger wrote:
> USE=xattr is needed nowadays to support:
> - filesystem caps (those things that let you drop set*id and generally
>    improves system security w/little to no runtime overhead)
> - PaX file markings (replaces binutils ELF markings)
> - selinux
>
> we actually have USE=filecaps on by default already, and catalyst
> hard requires tar[xattr] in order to work.  the hardened profile
> also package.use.force's this flag on for some core packages.
>
> not too many packages actually utilize this flag, and when they do,
> it's to pull in the attr package which clocks in at <200 KiB.  the
> runtime overhead tends to be low to non-existent as xattrs tend to
> be used only when requested.
>
> when support is not available in the FS or kernel, packages should
> generally fall back gracefully.
>
> anyone opposed to flipping this flag on by default ?

do it.  the only problem i see coming is kernel configurations which 
don't have xattrs set.  this can happen on embedded boards where its 
difficult/impossible to swap out kernels (like some of the stuff i 
have).  fcaps.eclass has intelligence for this.  i'll look again at 
pax-utils.eclass and make sure there is enough error checking to deal 
with kernel/filesystems that can't handle xattrs.  i remember some issue 
with scanfelf's exit code which caused some problem, but we can talk 
about that later when i've refreshed the issue in my head.

>
> reference:
> https://bugs.gentoo.org/506198
> https://bugs.gentoo.org/556408
> -mike


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA