| Summary: | Unable to unmount autofs filesystems inside a container | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Berrangé <berrange> | ||||
| Component: | kernel | Assignee: | Ian Kent <ikent> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | dhowells, gansalmon, ikent, itamar, jonathan, kernel-maint, madhu.chinakonda | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-11-21 11:22:52 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Daniel Berrangé
2011-10-13 12:18:49 UTC
Created attachment 527963 [details]
Demo unmount inside a container
Have you sent a query on this upstream at all? I have mentioned this in private email to Ian Kent a few weeks back. Adding Ian and David to CC. A little more investigation shows that this is where the umount
failure occurs:
SYSCALL_DEFINE2(umount, char __user *, name, int, flags)
{
.....
retval = -EPERM;
if (!capable(CAP_SYS_ADMIN)) {
printk(KERN_INFO "umount: CAP_SYS_ADMIN check failed\n");
goto dput_and_out;
}
...
}
The printk() is mine and triggers when I run the test.
It seems to me that root user does not inherit CAP_SYS_ADMIN over
the clone() call. The same test is done during mount so that must
be forbidden as well.
I don't doubt there will be other challenges but we can't even
start to work out what they are if umount and mount are denied
by the CAP_SYS_ADMIN check.
A quick Goolge search shows that this difficulty is well known
but I didn't see any sensible way of overcoming it. Mind you the
date on posts was some months ago and that may have changed since.
Ian
> It seems to me that root user does not inherit CAP_SYS_ADMIN over
> the clone() call.
This is very odd, capabilities are untouched across clone(), and containers definitely have the ability to mount()/umount() filesystems because in libvirt, by the time we hit the autofs problem, we've already mounted & unmount many many other filesystems since the clone() call.
> This is very odd, capabilities are untouched across clone(),
Arrrrrrrrrrrggggh, my fault :-(
My demo program has the CLONE_NEWUSER flag set. Prior to 3.x kernels, this was effectively a no-op, but it now has special meaning wrt containers.
Please modify the demo program in this BZ to remove the CLONE_NEWUSER flag, and you should then see the real autofs problem.
Ok, after fixing the demo program, it appears that there is *not* any autofs problem in the kernel 3.1 or later. It must have been fixed sometime between 3.0 (where I originally saw the problem) and 3.1. Sorry for the noise. (In reply to comment #9) > Ok, after fixing the demo program, it appears that there is *not* any autofs > problem in the kernel 3.1 or later. It must have been fixed sometime between > 3.0 (where I originally saw the problem) and 3.1. Sorry for the noise. Yes, there was a change that I believe went into 3.1.0-rc9. This is the only other (we had one other) reported problem caused by the initial vfs-automount implementation. That means I'll need to remember this if (when) I lobby to re-introduce that semantic behaviour. Thanks, is there anything else we need to investigate? WRT to F16/rawhide I believe we're all OK with autofs + LXC now. |