Summary: | failure building baselayout-1.12.13 with a ro /dev | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ciprian Dorin Craciun <ciprian.craciun> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | pchrist |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Ciprian Dorin Craciun
2010-03-07 13:00:39 UTC
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. |