Re: [systemd-devel] container /proc/filesystems owned by nobody:can't upgrade

[Mike Gilbert]

On Tue, Oct 3, 2017 at 11:38 AM, arnaud gaboury
 wrote:
> On 10/03/2017 05:19 PM, Mike Gilbert wrote:
>
> On Tue, Oct 3, 2017 at 4:01 AM, arnaud gaboury 
> wrote:
>
> 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.

Ah, I misread that. Yes, this would be a Fedora bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] container /proc/filesystems owned by nobody:can't upgrade

[Lennart Poettering]

On Di, 03.10.17 10:01, arnaud gaboury (arnaud.gabo...@gmail.com) wrote:

> 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

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Starting service conditionally and retrying when failure

[sdrb]

Mantas Mikulėnas wrote:

On Thu, Oct 5, 2017 at 7:51 AM, sdrb > wrote:

Hi,

I'd like to ask how to achieve following functionality in systemd:

I'd like to start alsa-restore.service only once just after one of
the specified files appears. Those file matches: /dev/snd/control*.

For now I have something like this:

[Unit]
Description=Save/Restore Sound Card State
ConditionPathExistsGlob=/dev/snd/control*
After=sysinit.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/sbin/alsactl restore -f /etc/asound.state

[Install]
WantedBy=multi-user.target


but during the start when there is no any of /dev/snd/control* files
- the condition is not meet and the service is not going up.
Those files appears later.

So that what I'd like to achieve is to wait for appearing of those
files and then starting alsa-restore service.


Isn't that exactly what ALSA's
standard /usr/lib/udev/rules.d/90-alsa-restore.rules does?




Thanks for all the responses. As I prefer the easiest solutions I have 
chosen Camilo's solution with serviced.path.

Problem fixed. Thanks.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel