[lxc-users] Failed to reset devices.list (etc)

[Richard Hector]

Hi all,

I have messages like this in the logs on several of my (lxc, not lxd)
containers:

systemd[1]: phpsessionclean.service: Failed to reset devices.list:
Operation not permitted

systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
not permitted

systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
not permitted

systemd[1]: Failed to reset devices.list on
/system.slice/systemd-tmpfiles-clean.service: Operation not permitted

systemd[1]: Failed to reset devices.list on
/system.slice/apt-daily.service: Operation not permitted

Host is debian stretch, guests are a mix of debian and ubuntu.

Searching the web finds various results of various ages; some claim to
be fixed, others not.

Some claim it's an issue with unprivileged containers only, but AFAIK
I'm using privileged containers only (how do I tell?)

What I can't find is:

What is devices.list, what specifically (in each case) wants to reset
it, and why?

Can and should I stop it, and how?

There are some references to setting "PrivateNetwork=false" in the
service file (for the phpsessionclean one, at least) - but that didn't
seem to have any effect.

Any tips?

Thanks,
Richard

[Christian Brauner]

Post by Richard Hector
Hi all,
I have messages like this in the logs on several of my (lxc, not lxd)
Operation not permitted
systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
not permitted
systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/systemd-tmpfiles-clean.service: Operation not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/apt-daily.service: Operation not permitted
Host is debian stretch, guests are a mix of debian and ubuntu.
Searching the web finds various results of various ages; some claim to
be fixed, others not.
Some claim it's an issue with unprivileged containers only, but AFAIK
I'm using privileged containers only (how do I tell?)
What is devices.list, what specifically (in each case) wants to reset
it, and why?
Can and should I stop it, and how?

No need to stop it. systemd will simply gracefully move one but report
an error. The devices.list regulates to what devices a privileged
container can have access to. The container not being able to mess with
it is very mucht wanted for security reasons. There's no way to stop it
from LXC's side. If you really care about this you could probably
disable all services that try to touch it. But it's really not needed.

Christian

Post by Richard Hector
There are some references to setting "PrivateNetwork=false" in the
service file (for the phpsessionclean one, at least) - but that didn't
seem to have any effect.
Any tips?
Thanks,
Richard
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[Richard Hector]

Post by Christian Brauner

Post by Richard Hector
Hi all,
I have messages like this in the logs on several of my (lxc, not lxd)
Operation not permitted
systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
not permitted
systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/systemd-tmpfiles-clean.service: Operation not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/apt-daily.service: Operation not permitted
Host is debian stretch, guests are a mix of debian and ubuntu.
Searching the web finds various results of various ages; some claim to
be fixed, others not.
Some claim it's an issue with unprivileged containers only, but AFAIK
I'm using privileged containers only (how do I tell?)
What is devices.list, what specifically (in each case) wants to reset
it, and why?
Can and should I stop it, and how?

No need to stop it. systemd will simply gracefully move one but report
an error. The devices.list regulates to what devices a privileged
container can have access to. The container not being able to mess with
it is very mucht wanted for security reasons. There's no way to stop it
from LXC's side. If you really care about this you could probably
disable all services that try to touch it. But it's really not needed.

Thanks Christian,

So my understanding is: The systemd service file tries to restrict what
the service can access, for security, by altering the devices.list

The container won't let anything mess with devices.list, for security.

The two can't both happen at the same time.

Is that about right?

Is it not possible to say "you can make it tighter, but not looser"?

I guess I just add it to my logcheck ignores and carry on?

Thanks,

Richard

Post by Christian Brauner
Christian

Post by Richard Hector
There are some references to setting "PrivateNetwork=false" in the
service file (for the phpsessionclean one, at least) - but that didn't
seem to have any effect.
Any tips?
Thanks,
Richard
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[Christian Brauner]

Post by Richard Hector

Post by Christian Brauner

Post by Richard Hector
Hi all,
I have messages like this in the logs on several of my (lxc, not lxd)
Operation not permitted
systemd[1]: run-user-1000.mount: Failed to reset devices.list: Operation
not permitted
systemd[1]: apt-daily.service: Failed to reset devices.list: Operation
not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/systemd-tmpfiles-clean.service: Operation not permitted
systemd[1]: Failed to reset devices.list on
/system.slice/apt-daily.service: Operation not permitted
Host is debian stretch, guests are a mix of debian and ubuntu.
Searching the web finds various results of various ages; some claim to
be fixed, others not.
Some claim it's an issue with unprivileged containers only, but AFAIK
I'm using privileged containers only (how do I tell?)
What is devices.list, what specifically (in each case) wants to reset
it, and why?
Can and should I stop it, and how?

No need to stop it. systemd will simply gracefully move one but report
an error. The devices.list regulates to what devices a privileged
container can have access to. The container not being able to mess with
it is very mucht wanted for security reasons. There's no way to stop it
from LXC's side. If you really care about this you could probably
disable all services that try to touch it. But it's really not needed.

Thanks Christian,
So my understanding is: The systemd service file tries to restrict what
the service can access, for security, by altering the devices.list
The container won't let anything mess with devices.list, for security.
The two can't both happen at the same time.

Yes.

Post by Richard Hector
Is that about right?
Is it not possible to say "you can make it tighter, but not looser"?

Yes.

Post by Richard Hector
I guess I just add it to my logcheck ignores and carry on?

Yes.

:)
Christian

Post by Richard Hector
Thanks,
Richard

Post by Christian Brauner
Christian

Post by Richard Hector
There are some references to setting "PrivateNetwork=false" in the
service file (for the phpsessionclean one, at least) - but that didn't
seem to have any effect.
Any tips?
Thanks,
Richard
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users
_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

_______________________________________________
lxc-users mailing list
http://lists.linuxcontainers.org/listinfo/lxc-users

[Richard Hector]

Post by Christian Brauner

Post by Richard Hector
So my understanding is: The systemd service file tries to restrict what
the service can access, for security, by altering the devices.list
The container won't let anything mess with devices.list, for security.
The two can't both happen at the same time.

Yes.

Post by Richard Hector
Is that about right?
Is it not possible to say "you can make it tighter, but not looser"?

Yes.

Post by Richard Hector
I guess I just add it to my logcheck ignores and carry on?

Yes.
:)
Christian

Thanks :-)

Where's the best place to read more about this?

Thanks,
Richard