Marcus Meissner wrote:
If you _create_ it under that Component it will get stricter permissions.
--- That is not clear from the bug interface. What is clear is the tick-box at the bottom that says to make the information only available to suse-security. Classifying something as security relevant doesn't mean it is a security vulnerability. Clicking a 'sensitivity' box to indicate that it is sensitive is pretty clearly indicating it is sensitive -- not just something to do with security. 2nd prob. When I first filed the bug, a few weeks ago, the security implications were not clear.
The rbash angle was not clear yet, but I am not sure it is real either.
If a user is running under 'rbash', and a SuSE-only patch always switches that to /bin/sh (ignoring the shell the user is running under), you can be certain it is a problem. It was tested.
Either way, the bash maintainer and we will take a look when we get to work on Monday.
--- The original problem (without the security implications) was reported over a week ago, with my concerns being brushed off with justifications for why a 5 year old patch against a much older version of the product should be kept -- because it might protect against some future problem. That logic is a reason for never removing any patch and is IMO, bad practice. It certainly isn't the only instance of such. I thought you guys were generally *at least* as knowledgable (usually more so) about these products. (I am serious... I don't usually assume the other people are stupid -- more often, I assume they know their product better than me, because it is their product (that an usually I'm told that I don't know what i'm talking about...;-))... Just like the business with "App compat between versions of OpenSuse (specifically related to perl, but including others)," where I fought to keep a bug from being closed as invalid. It it was important for me to do so, I could find security sensitive issues related to suse choosing not to go with upstream defaults and going with special patches and new, untested features. Suse doesn't even test their products anymore on loaded production systems, because it shows up too many problems. That's all but guaranteeing not only problems, but a higher-than-normal security-vulnerability rate as security vulnerabilities are proportional to bug count and inversely proportional to amount and complexity of testing. But such statistics are well known in the field, and I have presumed that the people choosing sterile build & test know the security implications of doing such. Telling customers in the field that their config isn't supported is scant comfort if they've been subject to a security vulnerability due to known, increased security risks of the current development model. *At* least, I know the risks -- if I was paranoid enough, I'd be running BSD, not linux. It's also the case that there is a tradeoff between user-friendliness and functionality vs. higher security. I've chosen Suse for over 10 years, despite knowing that my computer would be safest, enclosed in several feet of cement -- but it's really hard to use that way... ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org