Summary: | sys-apps/portage: "Unable to unshare" messages could be more specific, and could be deduplicated | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | bertrand, dflogeras2, esigra, girolimetti, konstantinos.smanis, sam, simon.vanderveldt+gentoo, tomek |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://github.com/gentoo/portage/pull/487 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Zac Medico
2019-03-15 16:21:25 UTC
This is reproducible by installing docker on e.g. Centos7 and run a gentoo image. I'm able to suppress the warning with: FEATURES="-ipc-sandbox -network-sandbox -pid-sandbox" I tried also different combo, but I can suppress the warning only by disable all the three feature. @Zac Medico, did you manage to find a way to make these messages more specific? I've had a couple of occasions where I got a bunch of "Unable to unshare: EPERM" but it's not really clear what's causing them. So far I've only seen this happen in a Docker container btw, not on my host itself. (In reply to Simon from comment #2) > @Zac Medico, did you manage to find a way to make these messages more > specific? I think we probably should make it simply display all of the enabled FEATURES that contribute to the unshare flags. Generally, all unshare calls will fail in a docker container that's not running in privileged mode, and you can use this to disable all of the relevant FEATURES: export FEATURES="-ipc-sandbox -mount-sandbox -network-sandbox -pid-sandbox" Also, if the container does not have ptrace capabilities (--cap-add=SYS_PTRACE), then you'll also want FEATURES="-sandbox -usersandbox". I think it would be useful to implement a simpler way to disable FEATURES that are not expected to work in an unprivileged docker container, for example we could implement something like FEATURES="-ptrace -unshare" that would disable all of the relevant FEATURES that are not expected to work. (In reply to Zac Medico from comment #3) > (In reply to Simon from comment #2) > > @Zac Medico, did you manage to find a way to make these messages more > > specific? > > I think we probably should make it simply display all of the enabled > FEATURES that contribute to the unshare flags. Generally, all unshare calls > will fail in a docker container that's not running in privileged mode, and > you can use this to disable all of the relevant FEATURES: > > export FEATURES="-ipc-sandbox -mount-sandbox -network-sandbox -pid-sandbox" > > Also, if the container does not have ptrace capabilities > (--cap-add=SYS_PTRACE), then you'll also want FEATURES="-sandbox > -usersandbox". There's no easy way to determine which specific unshare call/feature caused the "Unable to unshare" message? I think a more specific message, like "IPC sandbox: Unable to unshare" or something like that would already help a lot with giving a user some information to act on. (In reply to Zac Medico from comment #4) > I think it would be useful to implement a simpler way to disable FEATURES > that are not expected to work in an unprivileged docker container, for > example we could implement something like FEATURES="-ptrace -unshare" that > would disable all of the relevant FEATURES that are not expected to work. Flags that aggregate several options would be easy, but wouldn't that clutter FEATURES? Or would these two new flags replace the specific sandbox ones? A user still needs to know which flags exist and what they do, speaking for myself, I'd need to lookup what the IPC/mount/etc sandbox or unshare does and if/how I can disable it. Once I've done that there's not much difference between adding one or four things to FEATURES to me. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9557f104aa85b65c7d394c52c5c8d8727a111651 commit 9557f104aa85b65c7d394c52c5c8d8727a111651 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-12-15 22:53:50 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-12-15 22:56:34 +0000 sys-apps/portage: Bump to version 2.3.82 #310009 emerge: Show package USE in conflict messages #680456 display relevant FEATURES when unshare fails #693454 emerge-webrsync: support gentoo-YYYYMMDD snapshots #702146 emerge: drop FEATURES=distcc-pump support #702970 emerge-webrsync: enable xz snapshots for tarsync Bug: https://bugs.gentoo.org/701268 Bug: https://bugs.gentoo.org/310009 Bug: https://bugs.gentoo.org/680456 Bug: https://bugs.gentoo.org/693454 Bug: https://bugs.gentoo.org/702146 Bug: https://bugs.gentoo.org/702970 Package-Manager: Portage-2.3.82, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.82.ebuild | 272 +++++++++++++++++++++++++++++++++ 2 files changed, 273 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=e385eee1614b7b1e296b0e9560ad2d87ace9ea69 commit e385eee1614b7b1e296b0e9560ad2d87ace9ea69 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-12-15 22:11:55 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-12-15 22:21:23 +0000 process: display relevant FEATURES when unshare fails For example, the message will now look like this: Unable to unshare: EPERM (for FEATURES="ipc-sandbox mount-sandbox network-sandbox pid-sandbox") Bug: https://bugs.gentoo.org/680456 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/process.py | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) Just after upgrade to sys-apps/portage-2.3.99-r2, I'm getting this messages when I run emerge -pu world Calculating dependencies.... Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox") Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox") Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox") Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox") Unable to unshare: EINVAL (for FEATURES="ipc-sandbox network-sandbox") The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=df8b23f97740c1f87501b552af8081aba99b8956 commit df8b23f97740c1f87501b552af8081aba99b8956 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-05-05 17:13:48 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-05-05 17:15:58 +0000 sys-apps/portage: Check for CONFIG_UTS_NS Reported-by: Tomek L <tomek@lutel.pl> See: https://github.com/gentoo/portage/pull/539 Bug: https://bugs.gentoo.org/680456#c8 Package-Manager: Portage-2.3.99, Repoman-2.3.22 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/portage-2.3.99-r2.ebuild | 2 +- sys-apps/portage/portage-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) *** Bug 721072 has been marked as a duplicate of this bug. *** Since we don't support Python <3.4 now, we can use functools.lru_cache to deduplicate messages. For testing i create this simple emerge@.service [Unit] Description=emerge %s [Service] Type=simple RestrictAddressFamilies=~AF_UNIX AF_INET AF_INET6 PrivateNetwork=true RestrictNamespaces=cgroup ipc mnt pid user ExecStart=/usr/bin/emerge %i I allow Namespaces for ipc/mnt/pid and get following error. emerge[]: Unable to unshare: EPERM (for FEATURES="ipc-sandbox mount-sandbox network-sandbox pid-sandbox") But if i disable only network-sandbox 'Environment=FEATURES="-network-sandbox"' the error message complete disappear. The Problem is that the error message should only output that network-sandbox don't work in the original systemd emerge unit. (In reply to salmander from comment #12) > emerge[]: Unable to unshare: EPERM (for FEATURES="ipc-sandbox mount-sandbox > network-sandbox pid-sandbox") > > > But if i disable only network-sandbox > 'Environment=FEATURES="-network-sandbox"' the error message complete > disappear. > > The Problem is that the error message should only output that > network-sandbox don't work in the original systemd emerge unit. We can fix it to determine which feature causes it to fail. It will have to retry the unshare call separately for each of the features in order to determine this. |