Hi !
I'm still not clear as to how the menu implementation is supposed to
*know* whether or not the user has root access (either via sudo, or by
knowing the actually root password. Having some mechanism in place
(which also needs to be defined) to set an env var such as USER_IS_ADMIN
sounds awkward and messy to me. Plus, it's not in-session changeable,
and requires a session restart to take effect (granted, changing admin
status doesn't generally happen often). Personally, I think using env
vars to do anything on a desktop level is the wrong approach.
Well, I'm not an experienced developper here, but I'm really willing to
work hard in order to make this right. The problem is I'm only hearing
"Wrong Way" messages, without anybody trying to lead me towards the
right door :)
We (I didn't decide all this all by myself) have already thought of
other solutions, none of which seemed better than this one. But if you
have a better idea, I will sincerely be glad to discuss about it, and
work on the code so that it can be implemented.
In addition, how do we know which method to use: sudo, gksu, su, etc.?
Does that need to be written in the spec (I thought it would be part of
the implementation part) ? How can this be distribution-independant,
when, for instance, not all distributions use sudo ?
Considering the problem I mentioned above, how does the implementation
know whether or not to ask for root access in an 'optional' case where
the user does indeed have root privileges.
I suppose you're talking about cases where an admin user would want to
run the program as non-admin (just to get info without changing it) for
more security ? I don't think there can be an easy solution for that,
except displaying two different menu entries (which seems of the
question) or asking the user every time. I proposed that if the user
does indeed have root privileges, root access should be provided (and
password asked) in an "optional" case. And in the current situation, I
don't think a user has the choice for this when running a program from
the menus (has he ?). But then again, if you see a better option, I'll
be glad to hear it.
Note also that, in a case
like sudo, a user may have privileges to run some applications as root,
and not others. There's no way to distinguish this ahead of time
without parsing /etc/sudoers.
Right. That's why I have been discussing with the guys from sudo. There
is a way to know (with the sudo command) whether a given user is
authorized to run a given command. But this requires that the user
inputs his password (which is out of the question when displaying
menus). And this need for a password seems important to the guys from
sudo, for security reasons (and I tend to believe them on this kind of
matter). Duplicating the sudo code (with slight changes) to make a
dedicated helper doesn't seem to be a very efficient way either.
And I don't see the point of adding complexity to the spec for something
cosmetic. With proper menu editors -- as defined by the spec -- users
should be able to remove items they don't want to see.
I don't think we're speaking about the same kind of users, here :) I'm
working to make GNOME (and Linux in general) easier to use for most of
the people, without giving up any of its stability. Asking to total
beginners (I mean beginners as in "Hey, I don't get the difference
between those two buttons on my mouse") to edit their own menus doesn't
seem really realistic to me.
Imagine you just bought a new TV and you're surprised to see that dozens
of debugging messages (none useful to you) still appear at the top of
the screen. You call the hotline : will you be happy if they tell you
"Oh yeah, we thought removing them was cosmetic stuff, but you can do it
yourself, just open the rear panel, exchange condenser C124 and
resistance B687, then weld tracks 685 and 431 together. We have included
a special tool to do this in the package, you'll see, it's easy". ?
I can see the usefulness of this addition for one thing only: the
ability of the menu system to know when admin access is required, and
provide a mechanism for the user to enter a sudo/su password when they
run the app.
This wasn't the main purpose, but I agree it's an useful consequence as
well.
Cheers,
Manu
_______________________________________________
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
