gksu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Feedback on new gksu features


From: Brian
Subject: Re: Feedback on new gksu features
Date: Sun, 17 Jul 2005 07:45:39 -0700

On Sun, 2005-17-07 at 16:23 +0300, Gustavo Noronha Silva wrote:
> Hello,
> 
> I've been working on implementing new features and fixing problems in
> gksu. I'd like to ask for feeback on a specific feature that has been
> added by applying a modified patch -- originally done by Szilard Novaki
> <address@hidden> and modified by me -- and on a feature
> request that came from ubuntu users.
> 
> I'm CC'ing the debian-gtk-gnome list as Debian is my main testing and
> development ground for gksu.
> 
> Here's the problem: currently gksu asks for the password and if it is
> correctly given and gnome-keyring is available it will want to store it.
> Next time it runs, unless always-ask-password option is trigered it will
> try to grab the password automatically from the keyring. Some detailes:
> 
>      1. gksu the app knows nothing about the gnome-keyring stuff, it is
>         hiden inside a more generic new API function in libgksu
>      2. the default keyring is used, which means the root password is
>         going to be stored forever and never asked anymore unless it
>         changes or the user uses gnome-keyring-manager to delete that
>         key
>      3. when gksu/gksudo do not need a password to run the program they
>         will show nothing to notify the user something which requires
>         root powers is going on
> Perhaps I could have the gnome-keyring stuff not be generic, but
> explicitely supported by libgksu, which would finally make it no more
> 'desktop-agnostic' API-wise so gksu app will be able to decide somehow
> if the user wants to store the password and to which keyring.
> 
I use gentoo as my distribution.  When choices like this are available
(as ./configure options) they are assigned "USE" flags.  There are
generic ones like "gnome", "kde" to enable them or specific ones for
specific functionality.  I think a ./configure option would be good.  As
more code is available for different desktops, it's option can be added.

> For the second problem, maybe I could use the session keyring by
> default, thus requesting that the user types the password again at least
> once per session. Allowing the admin/user to select which keyring they
> want to use is planned.
> 
I like this option better.  (Although I rarely log out.)  It is the more
secure choice.


> Third problem also has something in common with some people's complaint
> that gksudo will simply take advantage of sudo's timeout and run stuff
> without requesting the password. Should gksu show a dialog warning what
> it's going to do before actually performing the command with root power?
> 
> You can see some examples of confusion caused by this here:
> 
> https://bugzilla.ubuntu.com/show_bug.cgi?id=11996
> https://bugzilla.ubuntu.com/show_bug.cgi?id=12643
> (the solution proposed at this one looks pretty difficult to implement,
> though, unless gksudo also uses the gnome-keyring instead of relying on
> sudo's timestamp)
> 
> I'd like to hear your advice on this matter.
> 
> Thanks and cheers from Helsinki!,
> 

I have been developing a gtk gui frontend for gentoo's portage package
management system.  Since we did not yet have su/sudo support built-in
users that wanted to install/remove packages with it had to run it with
root privileges.  The complaint and subsequent feature request was to
indicate whether it was being run as root or not.  When run as a user it
let's the user browse the package database, etc..  So, I think a
"confirm root privileges" popup dialog should be default.  Perhaps a
config option to boldly bypass such a warning for those foolhardy users.
After all linux is about choice :)
> 
-- 
Brian <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]