I wanted to try Gentoo inside a LXC (Linux Containers) container, with devptmfs mounted ro at /dev. (My other mounts are ro /proc and /sys.) When building baselayout-1.12.13 it fails with the following error: ~~~~ !!! Cannot write to '/dev'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.12.13.ebuild merge !!! And finish by running this: env-update ~~~~ Although in the beginning it says: ~~~~ * Creating directories and .keep files. * Some of these might fail if they're read-only mounted * filesystems, for example /dev or /proc. That's okay! ~~~~ To solve the bug I've just restarted the container with rw /dev. (But I see this a s a security issue, although I use the cgroup access filtering to device nodes (I allow only tty, null, urandom, etc.)) Reproducible: Always Steps to Reproduce: 1. ## mount /dev as ro 2. $ emerge --buildpkg --quiet baselayout Actual Results: !!! Cannot write to '/dev'. !!! Please check permissions and directories for broken symlinks. !!! You may start the merge process again by using ebuild: !!! ebuild /usr/portage/sys-apps/baselayout/baselayout-1.12.13.ebuild merge !!! And finish by running this: env-update Expected Results: It should give an warning, but continue without touching /dev
Actually it seams that it breaks on: $ emerge --buildpkg --verbose --ask --quiet --deep system
Maybe you have a point here, don't know, but I think you could sacrifice some security in order to update your system(I mean that anyway updating your system on the fly is a security risk). I'll leave it to base-system@ to decide. Thanks for your report.
Well the problem is that sometime even root has no way to loosen the security. And this is my concrete case: I want to allow the root of the container to do whatever he wants with his own root file-system, start whatever processes he wants, maybe even access to some (white-listed) device nodes, but I don't want to allow him to create device nodes, or update their stats. (I don't even allow him raw access to network or mount or modprobe priviledges...) So I definitively see a possible problem here. But as you've said it's not my call, but the people taking the decision should be aware that an operating system should work in a lot of strange cases. (That's why I'm trying Gentoo as it's more customizable than the average Linux distribution.)
not sure this is relevant anymore
In my view this issue is `irrelevant` if one of the following is true: (a) the issue has been solved; (b) security itself became irrelevant; (c) Gentoo is not supposed to work in a constrained environment (like Linux containers); (and this would become a feature request;) I'm guessing it's either (b) or (c), but I would like to believe it's (c)... But anyway... I don't intend to reopen this issue, as if it wasn't solved by now, and nobody else showed any interest into the issue, then most probable it newer will. Thus because leaving an unresolved bug open is pointless, I agree to kill the issue.
(In reply to comment #5) > In my view this issue is `irrelevant` if one of the following is true: > (a) the issue has been solved; > (b) security itself became irrelevant; > (c) Gentoo is not supposed to work in a constrained environment (like Linux > containers); (and this would become a feature request;) > > I'm guessing it's either (b) or (c), but I would like to believe it's (c)... > > But anyway... I don't intend to reopen this issue, as if it wasn't solved by > now, and nobody else showed any interest into the issue, then most probable > it newer will. > > Thus because leaving an unresolved bug open is pointless, I agree to kill > the issue. Question is, can you reproduce the problem with >=baselayout-2 since =baselayout-1* is no longer supported
(In reply to comment #6) > Question is, can you reproduce the problem with >=baselayout-2 since > =baselayout-1* is no longer supported Unfortunately currently I can't, as I don't have that project's (that I was working on) environment active right now. (Maybe I'll restart that project some day soon...) But if I do get into the same situation I'll write a message here, and leave the decision, to reopen or not, for then.