/monitor! not coming into the box from a
separate box..
-Original Message-
From: fedora-list-boun...@redhat.com
[mailto:fedora-list-boun...@redhat.com]on Behalf Of R. G. Newbury
Sent: Saturday, January 24, 2009 7:22 PM
To: fedora-list@redhat.com
Subject: Re: Package Manager Denies Permission
No nuanced and masterfully persuasive oratory can disguise the fact that
someone has made *and enforced* a decision that *they know better
than the user* how THINGS MUST BE DONE purely because the doing, is
considered to be 'not best practice'.
In this particular case, the 'best
Jeff Spaleta jspal...@gmail.com wrote:
Kevin Kofler kevin.kof...@chello.at wrote:
But PolicyKit does not work in a root session:
https://bugzilla.redhat.com/show_bug.cgi?id=447266
Hmm...this is probably worthy of some nuanced and masterfully
persuasive oratory as to where to strike the
On Fri, 2009-01-23 at 12:10 -0500, R. G. Newbury wrote:
Jeff Spaleta jspal...@gmail.com wrote:
Kevin Kofler kevin.kof...@chello.at wrote:
But PolicyKit does not work in a root session:
https://bugzilla.redhat.com/show_bug.cgi?id=447266
Hmm...this is probably worthy of some
Aaron Konstam wrote:
On Fri, 2009-01-23 at 12:10 -0500, R. G. Newbury wrote:
Jeff Spaleta jspal...@gmail.com wrote:
Kevin Kofler kevin.kof...@chello.at wrote:
But PolicyKit does not work in a root session:
https://bugzilla.redhat.com/show_bug.cgi?id=447266
Hmm...this is probably
On Fri, Jan 23, 2009 at 1:20 PM, Aaron Konstam akons...@sbcglobal.net wrote:
On Fri, 2009-01-23 at 12:10 -0500, R. G. Newbury wrote:
Jeff Spaleta jspal...@gmail.com wrote:
Kevin Kofler kevin.kof...@chello.at wrote:
But PolicyKit does not work in a root session:
Jeff Spaleta wrote:
Is PolicyKit reconfigurable? Yes, you can do policy grants and
customize PolicyKit authorization behavior.
But PolicyKit does not work in a root session:
https://bugzilla.redhat.com/show_bug.cgi?id=447266
Kevin Kofler
--
fedora-list mailing list
On Thu, Jan 22, 2009 at 4:11 AM, Kevin Kofler kevin.kof...@chello.at wrote:
But PolicyKit does not work in a root session:
https://bugzilla.redhat.com/show_bug.cgi?id=447266
Hmm...this is probably worthy of some nuanced and masterfully
persuasive oratory as to where to strike the balance
On Tue, 2009-01-20 at 13:21 -0500, R. G. Newbury wrote:
It does not stop me from doing what I want to do. It just makes it more
difficult and time-consuming. It does not actually enhance security in
any meaningful way. And it disrespects me by implying that I effectively
do not have the
Richard Hughes wrote:
I don't think you need to patch gnome-packagekit, just fixing PolicyKit
would do it. You'll still get the nag-dialog, but that's still part of
the design.
You mean the PolicyKit password dialog? Indeed, the patch does not give out
blanket permissions to root, it only
On Tue, 2009-01-20 at 13:47 -0500, R. G. Newbury wrote:
And Dick.
My name is Richard.
You are not being helpful. Please stop being a dickhead. I am a big
boy.
Then please read the documentation, rather than insulting me on mailing
lists. You're not exactly showing yourself to be an adult
Kam Leo wrote:
It's the person in front of the keyboard/clicking mouse that makes the
difference. Throwing in a requirement to log in as a user just delays
the inevitable.
The difference is malicious software running under your user account. I
can't really judge how serious a threat it is,
On Wed, 2009-01-21 at 10:52 +0100, Kevin Kofler wrote:
I'm sure you (Richard) know all this,
but other readers might not, so I'm saving you the work of
replying. ;-) )
Thanks! :-)
Richard.
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe:
On Tue, 2009-01-20 at 09:53 -0800, Kam Leo wrote:
Well, if you can not trust a GUI then logging in as a user won't help
either. Once that user invokes superuser powers there is no difference
between him/her and root.
Incorrect. If the dialog stays as the user process (non-root) it can
Richard Hughes wrote:
Please read http://www.gtk.org/setuid.html
The GTK developers say do not run GUI code as root. They are the ones
who write the GUI code. As for gnome-packagekit, _I_ wrote the code.
That stuff affects setuid, i.e. where you're giving out blanket permission
to *anyone*
On Wed, 2009-01-21 at 11:36 +0100, Kevin Kofler wrote:
That stuff affects setuid, i.e. where you're giving out blanket
permission to *anyone* to run code as root.
Right.
What we're talking about in this thread is somebody who knows the root
password logging in as root on their own machine
Richard Hughes wrote:
Sure, but my point if that GTK code is untrusted, and just not designed
to be run with elevated privileges. A buffer-overflow is an easy exploit
if the code is running as uid 0, whether running as setuid or as root.
Why would you overflow a buffer on your own machine
On Thu, Jan 22, 2009 at 2:12 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Richard Hughes wrote:
Sure, but my point if that GTK code is untrusted, and just not designed
to be run with elevated privileges. A buffer-overflow is an easy exploit
if the code is running as uid 0, whether running as
On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan
pocallag...@gmail.com wrote:
On Thu, Jan 22, 2009 at 2:12 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Richard Hughes wrote:
Sure, but my point if that GTK code is untrusted, and just not designed
to be run with elevated privileges. A
On Wed, 2009-01-21 at 13:42 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan
pocallag...@gmail.com wrote:
On Thu, Jan 22, 2009 at 2:12 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
Richard Hughes wrote:
Sure, but my point if that GTK code is untrusted, and
On Wed, Jan 21, 2009 at 2:25 PM, Craig White craigwh...@azapple.com wrote:
On Wed, 2009-01-21 at 13:42 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan
pocallag...@gmail.com wrote:
On Thu, Jan 22, 2009 at 2:12 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
On Wed, 2009-01-21 at 15:59 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 2:25 PM, Craig White craigwh...@azapple.com wrote:
On Wed, 2009-01-21 at 13:42 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan
pocallag...@gmail.com wrote:
On Thu, Jan 22, 2009 at 2:12
On Wed, 2009-01-21 at 15:59 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 2:25 PM, Craig White craigwh...@azapple.com wrote:
On Wed, 2009-01-21 at 13:42 -0800, Kam Leo wrote:
On Wed, Jan 21, 2009 at 12:47 PM, Patrick O'Callaghan
pocallag...@gmail.com wrote:
On Thu, Jan 22, 2009 at 2:12
On Wed, Jan 21, 2009 at 2:59 PM, Kam Leo kam@gmail.com wrote:
The fallacy is believing you automatically obtain security by auditing
applications running on X for execution by the superuser or preventing
root from logging into X.
No one is suggestion that you automatically get security.
On Mon, 2009-01-19 at 10:16 -0800, Kam Leo wrote:
What's the difference whether the package got
installed by root or via su?
No difference. The difference is that if you're loading a GUI to do it,
you're running 500,000 lines of code as root in an untrusted
environment.
Richard.
--
On Tue, 2009-01-20 at 04:31 +0100, Kevin Kofler wrote:
bruce wrote:
just saw this thread. so, is there a way/solution to allow a root user
to use the gui/gnome/package update app
You need to patch both PolicyKit and gnome-packagekit.
PolicyKit patch here:
On Tue, Jan 20, 2009 at 1:30 AM, Richard Hughes hughsi...@gmail.com wrote:
On Mon, 2009-01-19 at 10:16 -0800, Kam Leo wrote:
What's the difference whether the package got
installed by root or via su?
No difference. The difference is that if you're loading a GUI to do it,
you're running
On Tue, 2009-01-20 at 09:53 -0800, Kam Leo wrote:
On Tue, Jan 20, 2009 at 1:30 AM, Richard Hughes hughsi...@gmail.com wrote:
On Mon, 2009-01-19 at 10:16 -0800, Kam Leo wrote:
What's the difference whether the package got
installed by root or via su?
No difference. The difference is that
From: Richard Hughes hughsi...@gmail.com
I don't think you need to patch gnome-packagekit, just fixing PolicyKit
would do it. You'll still get the nag-dialog, but that's still part of
the design.
I wish this kind of stupid arbitrary restrictions just got removed.
It's up to David upstream to
On Tue, Jan 20, 2009 at 10:03 AM, Craig White craigwh...@azapple.com wrote:
On Tue, 2009-01-20 at 09:53 -0800, Kam Leo wrote:
On Tue, Jan 20, 2009 at 1:30 AM, Richard Hughes hughsi...@gmail.com wrote:
On Mon, 2009-01-19 at 10:16 -0800, Kam Leo wrote:
What's the difference whether the package
On Tue, 2009-01-20 at 13:21 -0500, R. G. Newbury wrote:
From: Richard Hughes hughsi...@gmail.com
I don't think you need to patch gnome-packagekit, just fixing PolicyKit
would do it. You'll still get the nag-dialog, but that's still part of
the design.
I wish this kind of stupid
From: Kam Leo kam@gmail.com
Dickhead wrote
Logging in as root is like walking around with a loaded shotgun in
your
belt with no safety latch. You can't install packages as the root user
as it's simply not secure. Just use a normal user login.
WTF??? Does anyone know where this
On Mon, Jan 19, 2009 at 9:27 AM, Richard Hughes hughsi...@gmail.com wrote:
On Mon, 2009-01-19 at 10:03 -0500, R. G. Newbury wrote:
Clicking on the link gave the usual 'what do you want to do' message.
Clicking install raised a warning about installing as root. I clicked
continueand got a
On Mon, Jan 19, 2009 at 9:52 AM, Kam Leo kam@gmail.com wrote:
On Mon, Jan 19, 2009 at 9:27 AM, Richard Hughes hughsi...@gmail.com wrote:
On Mon, 2009-01-19 at 10:03 -0500, R. G. Newbury wrote:
Clicking on the link gave the usual 'what do you want to do' message.
Clicking install raised a
, January 19, 2009 10:17 AM
To: Community assistance, encouragement,and advice for using Fedora.
Subject: Re: Package Manager Denies Permission to Install
On Mon, Jan 19, 2009 at 9:52 AM, Kam Leo kam@gmail.com wrote:
On Mon, Jan 19, 2009 at 9:27 AM, Richard Hughes hughsi...@gmail.com
wrote:
On Mon
bruce wrote:
just saw this thread. so, is there a way/solution to allow a root user
to use the gui/gnome/package update app
You need to patch both PolicyKit and gnome-packagekit.
PolicyKit patch here: https://bugzilla.redhat.com/attachment.cgi?id=323469
Sorry, I don't have a patch for
36 matches
Mail list logo
