On 10/06/13 13:54, Daniel Pocock wrote:
> That screenshot appears to be Gnome 3. I log in with Gnome Classic so
> maybe I'm experiencing something different.
I did say "GNOME Shell". The "fallback" GNOME 3.4 session (which might
well be called "Classic" in the UI in wheezy) doesn't use Shell, so it
doesn't have access to the same way to mitigate this, and I would expect
it to use the standalone PolicyKit UI, which is just a normal user-level
application and looks like your screenshot.
GNOME >= 3.8 has a new "Classic" mode which uses Shell, but adjusts it
to look and behave more like GNOME 2. I don't know how its PolicyKit
dialogs behave - they're probably GNOME Shell modal dialogs in a more
GNOME-2-like (i.e. grey) colour scheme.
> I agree that having a modal dialog with a dimmed background would help,
> maybe this is meant to happen but the code is not working correctly in
> Gnome classic mode?
Fallback mode is/was a fallback for unsupported graphics hardware; it
doesn't have the UI that upstream intended, only an approximation. The
Shell-based session is "how it's meant to work".
> It was also demonstrated with Windows 7 that users could be tricked by
> web sites that simply dimmed the background of the browser window - so
> it is not a perfect solution and I would personally prefer to see users
> referred to initiate "su" or "sudo" on their own.
Sure, it's a mitigation, not a solution.
I don't think telling non-technical users they need to run cryptic
commands is desirable (they'll just not update at all!) and there are
technical limitations in su/sudo/gksu that are solved by PolicyKit[1],
but I agree that anything that asks for the user or root password should
be a response to user action.
In squeeze, the GNOME update notifier consisted of an icon in the
notification area which appeared when there were updates; when users
clicked on it, they were prompted for their password and could then
install the updates. That seems fine to me.
> Another way to do this might be telling them about updates at login time
> or when the screen is locked. Those are places where the user normally
> enters a password anyway. Immediately after they enter the password,
> the user could be informed about pending updates, within the same login
> UI, rather than having popups appearing out of nowhere.
That's an interesting idea; please suggest it upstream.
S
[1] among others:
* sanitizing the environment (done by sudo and PK but not by su)
* configurable level of authentication required
(done at an abstract level by PK, done at a command-line
level by sudo, not done at all by su)
* splitting privileged actions into an unprivileged GUI and a
privileged daemon, rather than running the GUI with privileges
(supported and encouraged by PK, not well-supported by sudo or su)
* ability to use system-modal prompting or a secure input path
(partially done by PK under GNOME Shell, likely to get better
under Wayland, not supported by sudo or su)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b5d6cb.5080...@debian.org
