Discussion:
container /proc/filesystems owned by nobody:can't upgrade
(too old to reply)
arnaud gaboury
2017-10-03 08:01:25 UTC
Permalink
Raw Message
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3

I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems. When
upgrading, it returns error:
< error: unpacking of archive failed on file /proc: cpio: chown >
$ ls -a /proc:
/proc/filesystems    -r--r--r--   1 nobody          nobody             0
Oct  3 09:53 filesystems

# chown root:root /proc/filesystems
chown: changing ownership of '/proc/filesystems': Operation not permitted

Same kind of error with a few other packages.

Can someone please help me to find a solution? Thank you
Anthony Joseph Messina
2017-10-03 14:35:25 UTC
Permalink
Raw Message
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems. When
< error: unpacking of archive failed on file /proc: cpio: chown >
/proc/filesystems -r--r--r-- 1 nobody nobody 0
Oct 3 09:53 filesystems
# chown root:root /proc/filesystems
chown: changing ownership of '/proc/filesystems': Operation not permitted
Same kind of error with a few other packages.
Can someone please help me to find a solution? Thank you
In my experience, certain packages need to be installed/upgraded from outside
the container to work around this. httpd is another one (if using user
namespacing) since it sets file attributes on /usr/sbin/httpd.

On a Fedora host (and a Fedora container), I do something like

dnf --releasever=26 --nogpgcheck \
--installroot=/var/lib/machines/mymachine --disablerepo='*' \
--enablerepo=fedora --enablerepo=updates upgrade filesystem httpd

I'm think Arch will also have a command to install/update files in the
container from the outside.
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6
arnaud gaboury
2017-10-03 14:58:17 UTC
Permalink
Raw Message
Post by Anthony Joseph Messina
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems.
When upgrading, it returns error: < error: unpacking of archive
failed on file /proc: cpio: chown > $ ls -a /proc: /proc/filesystems
-r--r--r-- 1 nobody nobody 0 Oct 3 09:53 filesystems # chown
root:root /proc/filesystems chown: changing ownership of
'/proc/filesystems': Operation not permitted Same kind of error with
a few other packages. Can someone please help me to find a solution?
Thank you
In my experience, certain packages need to be installed/upgraded from
outside the container to work around this. httpd is another one (if
using user namespacing) since it sets file attributes on /usr/sbin/httpd.
httpd is indeed one the few package I can't upgrade.
Post by Anthony Joseph Messina
On a Fedora host (and a Fedora container), I do something like dnf
--releasever=26 --nogpgcheck \
--installroot=/var/lib/machines/mymachine --disablerepo='*' \
--enablerepo=fedora --enablerepo=updates upgrade filesystem httpd I'm
think Arch will also have a command to install/update files in the
container from the outside.
I will investigate this direction.
Thank you for your hints.
Post by Anthony Joseph Messina
_______________________________________________ systemd-devel mailing
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Mike Gilbert
2017-10-03 15:19:00 UTC
Permalink
Raw Message
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems. When
< error: unpacking of archive failed on file /proc: cpio: chown >
/proc/filesystems -r--r--r-- 1 nobody nobody 0
Oct 3 09:53 filesystems
# chown root:root /proc/filesystems
chown: changing ownership of '/proc/filesystems': Operation not permitted
Same kind of error with a few other packages.
Can someone please help me to find a solution? Thank you
I find it strange that a package upgrade would be trying to install
the /proc directory on a running system. That's a directory that
should only really be touched when performing an initial install; any
other time, /proc will be mounted already and packages should not
touch it.

I would report this as a bug to Arch.
arnaud gaboury
2017-10-03 15:38:45 UTC
Permalink
Raw Message
On Tue, Oct 3, 2017 at 4:01 AM, arnaud gaboury
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems.
When upgrading, it returns error: < error: unpacking of archive
failed on file /proc: cpio: chown > $ ls -a /proc: /proc/filesystems
-r--r--r-- 1 nobody nobody 0 Oct 3 09:53 filesystems # chown
root:root /proc/filesystems chown: changing ownership of
'/proc/filesystems': Operation not permitted Same kind of error with
a few other packages. Can someone please help me to find a solution?
Thank you
I find it strange that a package upgrade would be trying to install
the /proc directory on a running system. That's a directory that
should only really be touched when performing an initial install; any
other time, /proc will be mounted already and packages should not
touch it. I would report this as a bug to Arch.
If it is a bug, it shall be reported on Fedora, which is the OS running
in the container, and not Arch which is the host.
Mike Gilbert
2017-10-05 15:13:32 UTC
Permalink
Raw Message
On Tue, Oct 3, 2017 at 11:38 AM, arnaud gaboury
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems. When
< error: unpacking of archive failed on file /proc: cpio: chown >
/proc/filesystems -r--r--r-- 1 nobody nobody 0
Oct 3 09:53 filesystems
# chown root:root /proc/filesystems
chown: changing ownership of '/proc/filesystems': Operation not permitted
Same kind of error with a few other packages.
Can someone please help me to find a solution? Thank you
I find it strange that a package upgrade would be trying to install
the /proc directory on a running system. That's a directory that
should only really be touched when performing an initial install; any
other time, /proc will be mounted already and packages should not
touch it.
I would report this as a bug to Arch.
If it is a bug, it shall be reported on Fedora, which is the OS running in
the container, and not Arch which is the host.
Ah, I misread that. Yes, this would be a Fedora bug.

Lennart Poettering
2017-10-05 11:11:33 UTC
Permalink
Raw Message
Post by arnaud gaboury
My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
I can't fully upgrade my container as some files are owned by
nobody:nobody and can't change to root. An example is filesystems. When
< error: unpacking of archive failed on file /proc: cpio: chown >
/proc/filesystems    -r--r--r--   1 nobody          nobody             0
Oct  3 09:53 filesystems
# chown root:root /proc/filesystems
chown: changing ownership of '/proc/filesystems': Operation not permitted
Same kind of error with a few other packages.
Can someone please help me to find a solution? Thank you
Files in /proc being owned by "nobody" is an artifact of user
namespacing, as these files are owned by "root" on the host, which
doesn't exist in the container, and is hence mapped to the 'catch-all'
"nobody" user.

One way out could be to disable userns for the container (by dropping
--private-users from the cmdline). This makes things a lot less
secure, but removes any mapping of users, and the host root and the
container root will be identical.

You should be able to switch between --private-users and no
--private-user freely, and hence to this only temporarily.

Quite frankly, it's a bit of a shortcoming of RPM/fedora, that this
exists. It might be worth filing a bug against the relevant packages
or RPM so that they deal with this... I mean, sooner or later they
have to deal with the reality that is userns which makes changes like
this to their execution environment.

Lennart
--
Lennart Poettering, Red Hat
Loading...