Final (hopefully) privilege escalation policy draft
Davide Cescato
ceski at fedoraproject.org
Sun Feb 14 18:42:12 UTC 2010
> I have now adjusted the draft -
>
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
- to reflect all feedback
> from this list and from FESco. It will be reviewed again by FESco
> next week.
> Please raise any potential issues or further suggestions for
> adjustments before then.
I just noticed that updating an already installed package no longer is
on the list of actions requiring administrative privileges. This was not
the case in earlier versions of the policy, which I found correct. The
change entered the policy starting from the draft published on February
1. After a quick search, I was unable to find a justification for this
change.
IMHO, not every administrator likes to have updates applied by console
users. In the (unfortunately not so rare) case of an update that
introduces a regression, an unprivileged user without administrative
authentication should not be able to perform the update, as this action
may change the behavior of the system "as a whole" (I am reusing some
words from one sentence in the policy's "Scope" section).
Back in November, I had expressed my concerns on this matter in a
comment to the infamous PackageKit bug
https://bugzilla.redhat.com/show_bug.cgi?id=534047#c257
My comment and the citation of a previous e-mail by Owen Taylor describe
practical scenarios where allowing updates by local users is not
appropriate. I guess that due to the flood of comments in that bug, my
comment went unobserved. However, it was cited even on
http://lwn.net/Articles/371587/
in the context of the "share of pitfalls" of the privilege escalation
policy. IMHO, I still think that, by default, only an administrator
should be able to update packages, and I think the policy should be
modified accordingly. I am aware that an out-of-the-box F12 system
allows console users to perform updates, but I would be happy to see
this decision reverted in time for F13.
More information about the devel
mailing list