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

Re: Bug#271567: Can you disables the "locking" of the keyboard, mouse, ...


(Disclaimer: I never coded C seriously for any useful commands.)

On Mon, Jan 17, 2005 at 11:24:05PM -0200, Gustavo Noronha Silva wrote:
> Em Qui, 2005-01-13 às 19:12 +0100, Osamu Aoki escreveu:
> >  * Parsing of GNU long-option and /etc/gksu.conf may share codes.
> I don't know what you mean, maybe I'm doing some dumb thing on my patch,
> but I don't think how to completely share code here.

First add these extra long options to "struct option long_opts[] = { ..."

Then right before calling "gtk_init (&newargc, &newargv);" you source
/etc/gksu.conf and treat each line (not started with #) being part of
long option on the command line arguments by appending to this command
line option, I guess, to list started with &newargv.  (I forgot how
argument is passed to getopt_long function.  But as long as the logic of
parsing command line arguments is properly combined with gksu.conf
parsing, it should work.)

At last, assign short option character to each long options.

getopt_long is shared this way.

> >  * All /etc/gksu.conf entries to match gnu-long-options of gksu command-line
> >  * add new long-option: --force-grab
> Why add this? I don't see a reason.

Without this, once account is compromised, it is easy to mkodify user
menu to --allow-grab and you may unknowlingly run gksu while other
process watching the keystroke of root password.  By preventing it
forcebly, it gives extra thin layer of protection.

> >  * add new long-option: --sudo-mode (Start it with gksudo mode)
> Done.
> >  * add new long-option: --limit-uid=UID1:UID2:UID3:...
> >  * add new long-option: --limit-gid=GID1:GID2:GID3:...
> If we add this, then we really need to have the gksu.conf have priority
> over user-options, or this simply should not be a long option at all,
> because gksu has no suid parts, so a user can simply build a costumized
> version which will ignore this. I don't see a real point.

This is for a system user should not even try to run program with gksu.
Since menu will present these program such as synaptic, people expect
something to happen by entring password.  We may give them a chance to
break it by chance (root password may be easy one to guess.).  Why not
just tell "You are not allowed tun this program."  This is more for
administerd host.  Totally wishlist item you canm ignore this time.

> >  * add new long-option: --prompt (prompt before locking I/O)
> >  * add new long-option: --no-prompt (do not prompt before locking I/O: default)
> Then we only need one of these.

* add new long-option: --prompt (prompt before locking I/O)
only is fine with me.

> > I think the setting in /etc/gksu.conf should have priority over
> > command-line so super user controls this command's behavior.  Gksu
> As I explained above, I don't see a reason for this to be like this. I
> think it should contain defaults, not mandatory options.

If you chose not to impliment --limit-uid/gid thingy, this is true.

> > simple trick to prevent freeze for start-up situation.  This is not
> > fancy trick which works for Gnome or KDE.  Just provide prompt screen
> > before locking I/O.
> That's a solution, but I would still love to find out how to play with
> session stuff without adding a Depends on libgnomeui.

Prompting is ugly hack but certainly avoid it without Depends on
libgnomeui.  If you find a good alternative, I will be happy with that too.

> > Then you can close all the bugs I listed in the previous mail and no one
> > will complain.  We will add hints to README.Debian for SCIM.
> =D
> > PS: I browsed your code to find gksudo binary being the same hardlink as
> > gksu except filename.  Please also link gksudo.1 to manpage :-)
> Yeah, have to document gksudo again =/.
> I've made a simple patch, a first implementation for this whole that
> still needs to be polished a lot. Would you mind to apply it, test it
> and criticize it? Here:
> http://people.debian.org/~kov/gksu/patches/conf-file.diff
> It worked alright with a simple test config file:
> $ cat /etc/gksu.conf
> # isso é um comentário
> disable-grab = yes # isso é outro comentário
> # mais comentário

That is pt-br.  Although pt-br may be 2nd most spoken foreign language
in Japan, I do not understand :-(  (I used to hear quite a bit of pt-br
in the shopping center in suburban Nagoya when I was living in Japan.)


Reply to: