Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default
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] Re: [rfc] enable USE=xattr by default
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: bluen...@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
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
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: bluen...@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
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
[gentoo-dev] Re: [rfc] enable USE=xattr by default
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 > 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
[gentoo-dev] Re: [rfc] enable USE=xattr by default
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 > 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] Re: [rfc] enable USE=xattr by default
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: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Re: [rfc] enable USE=xattr by default
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
