-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot run apt-get update in rootless container with sufficient capabilities #2517
Comments
Same happens with the whole list:
|
Compare
with
|
Ah, I've figured it out. You need at least two entries in both uid and gid mappings. For anyone struggling with this, just check out how rootless docker is configured. E.g.:
means adding
this solves the problems. Also please don't copy and paste all those linux capabilities I've posted above, that's just for testing purposes. Those mapping seem to come from |
In my case it shows this:
same with gid_map.
|
@ashwani29 you need to add the following into your systems
Replace username with your system username Then add To make |
Thanks @rijenkii will surely try this as I wasn't able to do this yet, just one query do you know about |
Sorry, can't help you with that |
Ok no worry, thanks for replying. |
it seems the developers of apt went to great lengths to make it hard to use their software outside the context they envisioned. we can find this source code in apt-pkg/contrib/fileutl.cc (which i found after receiving those error messages after creating a ptrace hook to return fake success from SYS_chown): // enabled by default as all fakeroot-lookalikes should fake that accordingly
if (VerifySandboxing == true || _config->FindB("APT::Sandbox::Verify::IDs", true) == true)
{
// Verify that gid, egid, uid, and euid changed
if (getgid() != pw->pw_gid)
return _error->Error("Could not switch group");
if (getegid() != pw->pw_gid)
return _error->Error("Could not switch effective group");
if (getuid() != pw->pw_uid)
return _error->Error("Could not switch user");
if (geteuid() != pw->pw_uid)
return _error->Error("Could not switch effective user"); i.e. the software refuses to work if you don't use exactly the sandboxing mechanism they invented. the good news is that we can get it to work by simply removing the line with the username i'm commenting here in the hope other users getting those errors messages will find my solution, rather than having to mess around with capabilities to get it to work and generally wasting a lot of time. |
@rofl0r hi, thanks for this but it still requires sudo to download any package in
and using
|
Do we know of distro's that are not so incredibly limiting w.r.t. the package manager? I've had more luck with alpine's apk, it still issues many warnings about ownership, but at least they are not fatal errors. The only issue is alpine is musl-based, and I'd rather have a glibc-based distro. |
maybe there's a file in your rootfs you really can't access. i didn't get this. try to run
yes, for example the one of my own distro sabotage linux. i've been using this 20 line C program since forever to build the entire OS inside a chroot as a regular user. the right thing to do is to fail when a critical resource can't be accessed, not doing some bogus user id checks beforehand and refusing to operate if those fail. edit: i've written a short guide how to chroot as regular user to a minimal ubuntu rootfs: https://github.com/sabotage-linux/sabotage/wiki/Running-a-minimal-ubuntu-rootfs-as-regular-user |
openSUSE's zypper doesn't have this issue (so any RPM-based distro should probably work fine as well). But yes, the apt issue mentioned by @rofl0r is pretty well-known -- in fact I mention it in my original talk about rootless containers in 2017. The current solution (aside from switching distributions) is to use something like proot which makes those syscalls no-ops and fakes the results from Maybe it should be added to rootlesskit but I'm not sure if that's the right place to host the fix. |
how's that a better solution than fixing apt by removing one line in /etc/passwd (or even better contact the apt maintainers so they fix their stuff)? in case you didn't notice, proot (ptrace in general) has a quite hefty price. i recently wrote an app using my debuglib and ran my whole desktop under ptrace, and some apps became almost unusably slow. maybe the overhead was amplified due to 30+ processes being traced and serialized, but there will always be an overhead. additionally proot uses the pre-PTRACE_SEIZE ptrace api that can't properly deal with SIGSTOP/SIGCONT, and some programs using glib uses those and misbehave when SIGSTOP doesn't really stop the process. |
It's not a better solution, but it is a solution that solves the problem without needing to patch every program that acts suboptimally inside user namespaces (apt is not the only example, it's just one that most people run into first). There's no reason we can have a solution which solves the problem for most programs and then we go and patch the world separately (if you'd like to send patches to the Debian folks to remove their sandbox checks, be my guest). As for overhead, |
so far i've seen only two: apt and GNU tar which insists on chown()ing files when run as root (without --no-same-owner, which is impractical to add to every invocation), and returning a failure exit status when that fails. my ubuntu guide linked two comments earlier has a section how that can be easily binary-patched out, but i suppose GNU guys could be convinced that they turn the hard error into a warning and return success anyway. i don't really see why there's such a reluctance in the container scene to cooperate with the few misbehaving program's authors instead of trying to find ever new low-level solutions for the problem. (ftr, i did the first distro based on musl libc and had over 100 misbehaving programs patched).
i actually hoped i could convince you to do it, since the request coming from a developer of a well-known container solution would look a lot more legitimate than from some random distro dude. |
I mean, I can do it -- though there are far less combative ways to ask me to write and send patches to another project.
It's not reluctance to co-operate with other projects (speaking for myself, I contribute to many other projects). There are a couple of reasons why having workaround solutions in place is a good thing:
None of this means "we shouldn't fix upstream projects" (far from it), it's just that having a workaround solution is clearly better than not having one and I don't see why you feel so strongly that having a workaround solution is somehow negative. The alternative is that users have no way of working around a project that doesn't work in rootless containers. (Not to mention that for some more complicated cases -- such as faking |
This is how I got around it (thanks to @rofl0r commenting on apt internals above)
|
FWIW I've also had success with |
@mtmk good find! i used your approach and refined it a little bit more in my guide |
Only happens when systemd-sysv is installed in the container.
|
Similar to #1860. I can't seem to get a rootless ubuntu:18.04 container to run apt-get update, even with CAP_SYS_ADMIN.
The error I'm getting is:
With rootless docker I am able to actually run
apt-get update
. Any clue what's going wrong here?The text was updated successfully, but these errors were encountered: