drago01 wrote:
> The "feature" is called security. By your logic everyone should be
> root,
For home user machines, that wouldn't necessarily be a bad thing (but it
would mean fixing the software that special-cases the root user improperly
for no good reason).
Alternatively, the kernel could be patched to give "admin users" (either
defined as members of the "wheel" group as now, or by some additional
property that would be set for the same users by default) some strategic
capabilities such as dac_override. That would also put an end to the endless
annoyance of having to sudo all the time. (And by the way, sudo and
PolicyKit actions should be allowed with no password (rather than the user
password as now) for wheel group members by default.) That way, you still
get the benefits from different accounts, e.g., different preferences per
family member, without the current restrictions imposed to "normal" users.
The endless password prompts make a lot of sense in controlled corporate
environments with dedicated system administrators, but on home machines,
they are just an unnecessary annoyance.
>> * SELinux works by shipping a "policy" that effectively tries to specify
>> in one single place (read: single point of failure!) everything any
>> program in Fedora (scalability disaster!) ever wants to do
>> (second-guessing its actual code, i.e., duplication of all logic!).
>
> That's not how it works not how it supposed to work. Please read on MAC.
Uh, I know how it works. The above is how I summarize it. If you think that
is incorrect, please explain HOW.
>> * An update to that SELinux policy was shipped that BREAKS the most
>> critical tools in Fedora, the ones required to update the system and thus
>> install the fixes for any regressions, including the very regression that
>> caused the breakage. And also any automated workarounds are blocked by
>> design.
>
> No idea what "automated workaround" means but there are other ways to
> deal with it see Colin's post.
A %pretrans scriptlet that fixes the problem without manual user
intervention (other than OKing the update). But SELinux won't allow RPMs to
mess with it that way (especially without invoking an external executable,
which is blocked by the faulty policy) because it would defeat its flawed
security model.
> Yeah so we should find out why this happened and improve the testing
> procedures to not let it happen in the feature (again see Colin's mail).
NO amount of testing is going to prevent regressions from happening
occasionally. This means:
* we need to eliminate common sources of regressions such as SELinux, to
prevent whole classes of regressions from occurring in the first place
(prevention is better than duct tape!) and
* we have to accept that regressions can always happen and allow for fast
fixes to those regressions (direct stable pushes).
>> So, what needs to happen:
>> * SELinux must be disabled (or preferably, not installed in the first
>> place, to avoid wasting space for nothing) by default! Just consider the
>> benefits (none!)
>
> As stated above that's not true.
As stated above, that IS true. :-)
>> * The Update Policies must be repealed. This regression has shown us that
>> not only they totally failed at preventing it, but they are actively
>> contributing to exposing MORE users to broken updates by delaying
>> regression fixes. (This kind of regression fixes needs to go out DIRECTLY
>> to stable!)
>
> This is a contradiction "our current testing didn't find the bug so
> how about we do no testing at all".
There is no contradiction. Doing away with policies that do not work is
perfectly logical, as is allowing quick regression fixes because regressions
do happen no matter how much you test.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
