Summary: | pax-utils.eclass install/merge phases: setfattr: /var/tmp/portage/…: Operation not supported | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Conceptual/Abstract Ideas | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | hardened |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 193766 |
Description
Sergey S. Starikoff
2015-11-10 10:42:57 UTC
(In reply to Sergey S. Starikoff from comment #0) > > /var is placed on dedicated partition: > $ mount | grep var > /dev/sda6 on /var type reiserfs (rw,noatime) > > > It would be fine if such errors would be caught by portage and echoed after > update as QA warnings for Gentoo bug tracker. It's a user configuration issue, not a QA problem, so pax-utils.eclass calls elog (and with default configuration portage's "echo" elog module will echo the elog messages after the update). The messages originates from this line: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/pax-utils.eclass?id=b95c7dc6904efdea1b1bf7d55d2767759fa799be#n134 (In reply to Zac Medico from comment #1) > It's a user configuration issue, not a QA problem I agree, that it is my system's configuration issue. But this warning is hidden and present only on terminal and in temporary log file, cleaned on merge. So, without human monitoring this issue stays unknown and unfixed. That is not right. > so pax-utils.eclass calls > elog (and with default configuration portage's "echo" elog module will echo > the elog messages after the update). > > The messages originates from this line: > > https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/pax-utils. > eclass?id=b95c7dc6904efdea1b1bf7d55d2767759fa799be#n134 Thank you! I guess referencies to not installed utilities. So, maybe pax-utils.eclass should list dependencies, reqiered by each of not blank PAX_MARKINGS values like office-ext-r1.eclass does? This will solve the particuluar title issue by either setting proper value of PAX_MARKINGS in make conf or installing missed dependencies. (In reply to Sergey S. Starikoff from comment #2) > (In reply to Zac Medico from comment #1) > > It's a user configuration issue, not a QA problem > I agree, that it is my system's configuration issue. > But this warning is hidden and present only on terminal and in temporary log > file, cleaned on merge. > So, without human monitoring this issue stays unknown and unfixed. That is > not right. It sounds like you have a non-default PORTAGE_ELOG_CLASSES and/or PORTAGE_ELOG_SYSTEM setting. You can use this command to query those settings: portageq envvar PORTAGE_ELOG_CLASSES PORTAGE_ELOG_SYSTEM > > so pax-utils.eclass calls > > elog (and with default configuration portage's "echo" elog module will echo > > the elog messages after the update). > > > > The messages originates from this line: > > > > https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/pax-utils. > > eclass?id=b95c7dc6904efdea1b1bf7d55d2767759fa799be#n134 > > Thank you! > I guess referencies to not installed utilities. > > So, maybe pax-utils.eclass should list dependencies, reqiered by each of not > blank PAX_MARKINGS values like office-ext-r1.eclass does? > This will solve the particuluar title issue by either setting proper value > of PAX_MARKINGS in make conf or installing missed dependencies. I think you just need a filesystem with support for user.pax.* extended attributes (gentoo-sources includes 1500_XATTR_USER_PREFIX.patch to enable this for tmpfs). @hardened: What do you think about having the eclass give some more hints to the user? (In reply to Zac Medico from comment #3) > It sounds like you have a non-default PORTAGE_ELOG_CLASSES and/or > PORTAGE_ELOG_SYSTEM setting. You can use this command to query those > settings: > > portageq envvar PORTAGE_ELOG_CLASSES PORTAGE_ELOG_SYSTEM I don't overrided defaults: $ eselect profile list Available profile symlink targets: [1] default/linux/amd64/13.0 * … $ portageq envvar PORTAGE_ELOG_CLASSES PORTAGE_ELOG_SYSTEM log warn error save_summary:log,warn,error,qa echo > I think you just need a filesystem with support for user.pax.* extended > attributes (gentoo-sources includes 1500_XATTR_USER_PREFIX.patch to enable > this for tmpfs). Thank you! I've seen bug #465330 But here /var/tmp/portage is placed on real filesystem (reiser3). For now I use 4.1.6-aufs kernel with proper FS_XATTR support: $ zgrep XATT /proc/config.gz … CONFIG_REISERFS_FS_XATTR=y Tomorrow I'll make a check on another box with =sys-kernel/aufs-sources-4.0.5 kernel and /var/tmp/portage mounted as tmpfs. (In reply to Zac Medico from comment #3) > I think you just need a filesystem with support for user.pax.* extended > attributes (gentoo-sources includes 1500_XATTR_USER_PREFIX.patch to enable > this for tmpfs). My another Gentoo box with /var/tmp/portage mounted in tmpfs: # uname -r 4.0.5-aufs # mount | grep "/var/" none on /var/tmp/portage type tmpfs (rw,size=7168M) # zgrep TMPFS_XATTR /proc/config.gz CONFIG_TMPFS_XATTR=y FF build error: !!! Failed to copy extended attributes. In order to avoid this error, !!! set FEATURES="-xattr" in make.conf. !!! copy /var/tmp/portage/www-client/firefox-38.4.0/image/usr/lib64/firefox/firefox-bin -> /usr/lib64/firefox/firefox-bin failed. !!! Filesystem containing file '/usr/lib64/firefox/firefox-bin#new' does not support extended attribute 'user.pax.flags' >>> Failed to install www-client/firefox-38.4.0, Log file: … Probably, something wrong in sys-kernel/aufs-sources kernel. Not a portage bug. Please open new bugreport on aufs-sources, if you think that they can be source of this issue (In reply to Sergey Popov from comment #6) > Not a portage bug. Please open new bugreport on aufs-sources, if you think > that they can be source of this issue You aren't right. You resolution is INVALID. Looking on correctness of error handling in pax-utils.eclass this bug may be marked FIXED. Somewhere I use old reiserfs filesystem. For correct handling of PAX attributes it needs "user_xattr" mount option. And pax-utils.eclass probably should verify it at pre-merge checks phase. Because non-critical for /var/tmp/portage errors are critical for / (or /usr if separate and formatted in reiserfs, see error description in comment #5). Merge not only fails, but breaks existent FF installation, that is completely wrong and portage should not allow this. So, this bug may be REOPENED. P.S. Does this feature needs to be documented in Handbook: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System#About_fstab (In reply to Sergey S. Starikoff from comment #7) > Somewhere I use old reiserfs filesystem. For correct handling of PAX > attributes it needs "user_xattr" mount option. And pax-utils.eclass probably > should verify it at pre-merge checks phase. > Because non-critical for /var/tmp/portage errors are critical for / (or /usr > if separate and formatted in reiserfs, see error description in comment #5). > Merge not only fails, but breaks existent FF installation, that is > completely wrong and portage should not allow this. So, this bug may be > REOPENED. Yeah, portage could certainly check for security namespace support, in order to support capabilities for things like /bin/ping: # getfattr -d -m ".*" /bin/ping getfattr: Removing leading '/' from absolute path names # file: bin/ping security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= Maybe it should also check for user namespace support for hardened profiles. > P.S. Does this feature needs to be documented in Handbook: > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/System#About_fstab For non-hardened systems, user_xattr is not strictly necessary. However, the security namespace is required for capabilities support on regular linux systems as noted above (for /bin/ping). Probably, the Hardened/PaX documentation should explicitly mention user_xattr in some place(s), like here: https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart I see progress in this bug. In addition to install merge check is performed. But performing this check at phase step is not completely correct: it's unpleasant to get this error after a long-time build. So, they should be moved to pre-merge checks. (In reply to Zac Medico from comment #8) > Maybe it should also check for user namespace support for hardened profiles. This error appears not only on hardened profiles. So, this check should be more common. (In reply to Sergey S. Starikoff from comment #9) > I see progress in this bug. > In addition to install merge check is performed. > But performing this check at phase step is not completely correct: it's > unpleasant to get this error after a long-time build. So, they should be > moved to pre-merge checks. > > (In reply to Zac Medico from comment #8) > > Maybe it should also check for user namespace support for hardened profiles. > This error appears not only on hardened profiles. > So, this check should be more common. I have significantly decreased the noise from pax-utils.eclass. I have not however totally silenced it. It is important that people using a kernel that doesn't support 'user.pax.flags' xattr namespace on tmpfs be made aware that they are loosing XATTR_PAX markings. If they opt to switch to hardening in the future, they'll hit pax related bugs. They may also hit other bugs related to loosing extended attributes for other namespaces. We should encourage gentoo-sources or hardened-sources in Gentoo. For reference, here are the changes to the eclass: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bd9c5468dd0ba397121c5674e370346bd0d1ebef https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5d97f52774e256b670a95f42583e01a9c268b7e6 After today's update I've got a strange message: * Messages for package mail-client/thunderbird-38.5.0: … * * Failed to set XATTR_PAX markings -me /var/tmp/portage/mail-client/thunderbird-38.5.0/work/comm-esr38/tbird/mozilla/dist/bin/xpcshell. Althought filesystem supports xattrs: # mount | grep xattr … /dev/sda6 on /var type reiserfs (rw,noatime,user_xattr) And thunderbird was merged successfully. |