GNOME bug 549389, which has a couple of duplicates, says that if a window is owned by an app which is running as a user other than the user who’s running Metacity, then it should have “(as fred)” on the titlebars, just as it would have “(on chiark)” or whatever if you were running the app remotely. The obvious very useful case here is to have “(as root)” when you’re running a program as root, to remind you to be careful.
The code to do this exists in Bugzilla now, so we can check it into trunk at any point.
Other suggestions, some better than others, have included:
- Use an alternative theme for root windows
- Draw a red border around the window
- Use a label (a space as big as the titlebar immediately below it) saying “Root process”
- Say “(as superuser)” instead of “(as root)” in case users don’t know what “root” means
- Have a hint not to write the username in the titlebar so that apps which generally run as root, like the package manager, don’t have baffling information all over their titlebar.
9 thoughts on “Squib of the day: “(as root)””
I’m +1 on using an alternative theme for administrative windows, or better yet adding a new window-state to the theme-engine so one theme can properly theme both kinds of window, falling back to the “(as superuser)” suffix if a theme doesn’t have a special appearance for super-user windows.
I thought about having an extra hint to allow non-root apps to use the alternate theme if they were potentially destructive without requiring root access, but I can’t actually think of any such activities.
Alternative themes would be a bit of an upheaval and probably not as useful as your idea about window states, which I like. We’d presumably stick with the dichotomy of root/any-other-user, and not have a theme for running as various other non-root users.
The “(as superuser)”/”(as root)” part can be checked in now, though, whereas a change to the theme will result in pushing us up to theme format v3, so we’d want to do all such things in a separate branch and merge them to trunk all together. That’s no reason not to do it, of course…
The terminal example you depict in the screenshots probably isn’t the best use case, since the terminal is one of the few applications where the contents of a window can be running as a different user from the terminal itself. Personally I’d never run gnome-terminal as root – I’d run it as myself and use sudo/su.
A more useful example would perhaps be Nautilus windows – if one of those is running as root, I’d *really* love to have some outward sign of it.
You’re right that Nautilus would be a more useful example; I used xterm because it’s clear that it’s working because there’s already some sign that it’s running as root, though. Otherwise you wouldn’t be able to tell from internal evidence that the patch worked.
As author of one of the duplicates, I think the best would be to have some kind of more visually-catching hint, such as a red flag somewhere on the title, but anything is better than having no distinction, for me =).
I was going to ask about the policy for theme version-bumping, but I see there’s been a whole new post about that. :)
I’d have thought it would be possible to add a window-state to the theme in such a way that older versions of Metacity could still read it, but I don’t know how strict they are about ignoring things they don’t understand.
When I suggested a themeable alternate window state, I was thinking of a Macintosh screenshot I saw once, with a dialog-box whose title-bar was covered in black-and-yellow warning-stripes; I think that would be visually-catching enough. :)
“as root” seems like a better idea than “as superuser” to me. It’s more consistent with the “as user” usage, and on RBAC-based systems, root != superuser anyway.