PackageKit policy: background and plans

Matthew Garrett mjg at redhat.com
Sat Nov 21 23:42:17 UTC 2009


On Fri, Nov 20, 2009 at 07:43:58PM -0700, Stephen John Smoogen wrote:
> On Fri, Nov 20, 2009 at 7:19 PM, James Morris <jmorris at namei.org> wrote:
> >> I know basically nobody who, on a generally single user system,
> >> explicitly switches to a console to log in as root and perform package
> >> installs there.
> >
> > This is how I started doing things in 1993, although I changed to sudo a
> > few years back.
> 
> I also do it. I usually use the graphical tool once or twice a release
> and then find myself not able to do something that yum lets me do
> automatically so go back to just yum. Then again I have been doing it
> this way for about as long as James Morris. I find myself completely
> frustrated trying to do stuff on a Mac or Windows box when the gui is
> just spinning and I have no idea a) is it installing, b) is it
> crashing etc.

The reason I find it hard to believe that this practice is the standard 
one even amongst traditional UNIX users is that if it were, there'd be 
no SUID bit on the su binary.

> >> I definitely agree that there's a whole range of cases where this isn't
> >> the behaviour you want. But for the vast majority of our users, I don't
> >> think there's a real security issue here.
> 
> I think the vast majority of users would love everything to run like
> it was under Windows95 when you could just click on something and it
> worked without a password or login or anything. For the envisioned
> 'desktop' model is there a reason to have multiple users for the
> default? Is there a reason to have anything but root?

Yes. There's a range of acts that root is able to perform that even an 
admin user should not be able to perform without extra authentication. 
It's not even necessarily related to security - I don't want a bug in 
firefox resulting in it trying to write to /dev/sda rather than a file 
in my home directory, for instance.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org




More information about the fedora-devel-list mailing list