-
Notifications
You must be signed in to change notification settings - Fork 544
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
[system] Permission denied /proc/sys/fs/binfmt_misc inside LXD container #1662
Comments
or we leave it as-is because it's not breaking anything, it's just screaming for the permission denied but doesn't cause any harm so far. |
Looking https://github.com/lxc/lxd/blob/master/lxd/apparmor.go There might be more thing to make sure sosreport doesn't collect when inside a LXD container. |
Maybe we can add a verification that we are running inside an LXD container and append |
Should @BryanQuigley thought ? |
I'd want these kinds of Access Denied errors to be shown in the output in a general sense. We don't want to hide from the end user that we can't collect some files as root. The other #1299 permission denied errors (the rest of the forbidden paths in system) are a case that makes more sense to just exclude. I don't understand upstream's choice here. Why mount it and then prevent any access to it? |
Talking with Bryan this morning about this bug. Here's my most current chain of thought. Is there any real benefit to collect the entire /proc/sys ? I think that's the first question to ask ourselves. If yes, fine, if no, let's try to identify what we really care of. Once we answer the above, maybe we should consider stopping to instruct system.py to collect the entire content of /proc/sys/* and start isolating the /proc/sys trees per plugins ? Exactly like we do with log collection, letting each plugin collect their own respective log files, instead of collecting the whole /var/log/* like we used to.
Current trees:
If we go that route, does each plugin absolutely need everything under their subset ? If binfmt_misc/* not needed nor useful, then maybe we can simply stop collecting instead of workaround'ing it for lxc ? I'm just brainstorming here. Feel free to add your 2 cents. |
What about this ? sos/plugins/init.py
|
Here's an example inside a LXD container with no access to
|
That way the error is flagged but doesn't generate a traceback in the form of |
Running sosreport inside LXD, does not break anything besides showing a 'permission denied' message on sosreport when trying to list /proc/sys/fs/binfmt_misc inside an LXD container from system plugin.
We noticed a behaviour change from LXD 3.0.3 to 3.12.
The denial is cause on purpose by a apparmor lxd policy:
3.0.3 was working okay due to a bug, but new version 3.12 fix it for good, and now prevent sosreport to collect binfmt_misc as it used to only when LXD 3.12 and late is in used.
Adding
"/proc/sys/fs/binfmt_misc/*"
in the actualadd_forbidden_path
would work but will also penalize all other situation where collecting would have work just fine. Since so far this is isolated to LXD only, maybe system plugin might need its own separateadd_forbidden_path
for LXD related stuff ?LXD bug reference:
https://github.com/lxc/lxd/issues/5688
The text was updated successfully, but these errors were encountered: