applications run through gksu cannot use themes in ~/.themes

Thanks for your bug.

1) The default theme is Human on Ubuntu which is fine, what is the issue with it?

This problem has something to do with the fact that root apps have no idea about
the path to your theme in $HOME/.themes Any theme not install under
/usr/share/themes gets defaulted to plain gtk. This bug can be worked around
temporarily by creating a symlink under /usr/share/themes/ to your newly
installed theme.
    sudo ln -s $HOME/.themes/mycooltheme /usr/share/themes/
Perhaps there is some theme path variable that gksudo can be made to pass onto
these apps. It may be upstream as this issue and the workaround have existed
AFAIK since Gnome 2.8 under Debian sid/unstable.

Confirming what Seth said:

The problem is that if you use a theme that only exists in $HOME/.themes then an
app launched via gksudo shows up as unthemed GTK.

Reassigning to gksu. Michael, do you think that we should hack something to make
it use the user theme?

Michael, do you think that we should hack something to make it use the user theme?

Hmmm yes, I also find this bug very annoying, and it's so visible that fixing it
for Dapper would be a good idea, especially if Dapper's main focus is polish (?).

Might it not be be easy and safer to use a specific gtk theme for programs running as root, to mark them out from other apps? If there was a variation on the Human theme just for that, root running apps would not generally look out of place, whilst still letting the user know instantly that they are affecting system settings.

This would be even more effective augmented with a tag in the window title (a la running remote apps under metacity), but that's another story.

I've also experience this bug and found it makes for a very un-proffesional looking desktop for anyone that installs a theme through gnome-theme-manager.

I think when you launch an application with gksu, it be save the actual user session environment .

for example, when you execute "su user" you change the user but all session environment don't change and when you execute "su - user" then the session environment change to the user logged.

I think that if you launch some application with gksu it may use the user theme and "gksu -" the root theme.

Regards,
Chuchi

The apps are already started by gksu.

A fix that would prevent lots of problem is to update the default theme (Human) to support color-schemes. I believe the main reason people install different themes is because they don't like the colors. (not that the default colors are wrong, its just that different people like different colors).

In any case, for the look and feel, this bug really should be fixed. It is in any case weird that it doesn't look in ~/.themes while it does use the user's ~/.gtkrc ..

But putting a color chooser or making a beautiful theme for user and
root not is the solution.

When we access to admin utils with gksu, We must see the same theme
that the user, not the root theme!!

The problem not is make the user and root themes equals by default. If
I change the theme with black background in the widgets, when i launch
synaptic with gktsu i don't want to see the white background if the
root have configured in his theme.

On 2/21/07, Ralf Nieuwenhuijsen <email address hidden> wrote:
> A fix that would prevent lots of problem is to update the default theme
> (Human) to support color-schemes. I believe the main reason people
> install different themes is because they don't like the colors. (not
> that the default colors are wrong, its just that different people like
> different colors).
>
> In any case, for the look and feel, this bug really should be fixed. It
> is in any case weird that it doesn't look in ~/.themes while it does use
> the user's ~/.gtkrc ..
>
> --
> locally installed gtk themes not applied to admin apps
> https://launchpad.net/bugs/24280
>

I agree this issue is really annoying. But I've noticed that if I run an application from xterm using "sudo application" command line, I get that unthemed gtk controls. So it's not a gksu problem. It's a common issue related to using user themes by gtk.

I think that gtk should take into consideration not only user id that it's running under, but also a common context like who really owns the session and his themes/paths to themes.

The problem is that the path that GTK searches for themes is based on the user running the program. So, if you have a theme in ~/.themes, GTK will not be able to find it when running as a different user.

As Al says, this has nothing to do with gksu, gksudo, sudo, or su, it's simply that GTK is looking for a theme that is no longer available.

Since the theme is set in gconf, maybe the theme search path could be set there too? This would solve the problem as far as I can tell.

using sudo the gconf configuration read would not be the user one

Ah, I had assumed that the theme information was coming from gconf settings. I guess it comes from the users ~/.gtkrc ?

I can't test at the moment, but do apps run via sudo use the /root/.gtkrc ?

Tom, yes, it's going from gconf.

jed@jed:~$ find . -exec grep -l CleanBlue {} \;
./.gconf/desktop/gnome/interface/%gconf.xml
./.themes/CleanBlue/index.theme
jed@jed:~$

Sebastian probably meant that it's root's gconf.
So then gtk should learn x session owner (I guess the X server can give such information?) and
read his gconf setting with the theme name and path.

From my experiments is not about personal settings.
If I copy the themes to /usr/share/themes it can use them.

The program seems to lie with user-installed themes.
Currently, the correct theme _is_ selected, it is just not always available in /usr/share/themes or /root/.themes

My current workaround:
  - replace all users' ~/.themes with a symbolic link to /usr/share/themes.
  - changed the permissions to allow /usr/share/themes to be altered by all desktop users.

I wonder if this really creates a security issue?

Wait, i was a bit unclear. It actually uses the theme selected by the user, IF its available.
It has the correct setting. It doesn't try to use the theme from root's config at all. It tries to use the theme of the user. But the theme has to be available in /usr/share/themes or /root/themes.

So, it *IS* using the correct .gtkrc config and the correct gconf-config!
Its just not finding the theme, because its not in the appropiate directories.

Themes installed per user should only be used for the corresponding user. The behavior of gksu is correct.

Themes should be applied per session or login user not per uid. The person sat in front of the keyboard can reasonably expect to see the theme they set whether they are using a normal application or an application run through a privilege escalation tool. Sudo should you to do things with the root user's privileges, it should not 'make' you the root user. For example the following:

sudo ls ~

Lists my user's home directory, not that of root.

Perhaps its all very difficult to explain for everyone.
Last try:

  Tolan, sudo does NOT change the theme.
  GTK just can't find the theme because it isn't looking in the right directories.

  Because the theme is installed in the users' home directory, not in /usr/share/themes.
  GTK should just use the 'home' environment value (which is correct, as you point out)

Perhaps you could try not assuming everyone is an idiot.

I never said sudo changed the theme, my point was that *from the point of view of the user*, code run through sudo, such as GTK, should act as though it is being run by the session user, not the current GID/UID, for all things except permissions. The purpose of sudo is usually to gain the permissions of another user, not to 'be' that user.

So yes GTK should not set the theme based on UID/GID.

I am surprised that after two years this bug has still not been fixed.

Has anyone even started trying to fix it? Have the developers even discussed the problem? The bug is very visible, every user that installs a custom theme will see it when they use synaptic or any gksu app.

But is this easily fixed, or is this more of an architectual problem?
If its an architectual problem and the obvious solutions lead to security issues, the most obvious hack would be to enable a graphical way to install themes system-wide.

There is a graphical tool called gnome-art. It seems to be unmaintained though.
Perhaps some of the code there can merge with the appearance applet in the future.

A simple show filter that lets us choose between 'installed', 'available' could do the trick.
Another more ubuntu-way approach would be, to make the add button open up add/remove and add the 100 most popular themes to the ubuntu repositories automatically using some script.

That last solution would make the most sense, because some of these themes depend on gtk-engines not installed by default. It would be the same sort of solution as has been implemented within firefox.

With that scenarion, all we would need is a 'install more themes' button in the appearance window.
Off course the themes should get some sort of .desktop files to make them available in add/remove

ideally the user interfaces should not run as an another user. gksu could user the user theme if required though

Are there any security issues with using the users theme in an program running as root? If not, it doesn't seem like it would be too hard to do. (Although I don't really know the specifics of how that works)

Considering that to even get to that point the user has to have admin access, and that once the program is running any of the user's other applications could probably find a way to interact with the root application anyway, it doesn't seem so bad to me.

running user interfaces when not required is usually not a good idea and theme installation is an user feature and should not impact on the system configuration, if an administrator wants to add a theme he knows how to do that and doesn't need this tools

I'm not really sure if you're agreeing with me or not..

I agree that a user installing a theme shouldn't impact the system configuration, that's why I was saying that gksu should just allow the root application to use the users theme. (i.e. the one in ~/.themes)

I think the updated description to this bug confuses the issue. The problem is *not* that users can only install themes locally, the problem is that when a user installed theme is used the administration applications fall back to the default GTK theme (because they cannot find the user installed theme, obviously).

This is a problem because:

1- Un-themed GTK is unattractive to all but the most eclectic tastes.
2- It is not the expected behavior to people who don't understand how themes work.

Admittedly, this problem can be avoided. After all, if you can run administrator apps then you probably have the permission necessary to install themes globally. However, doing so requires knowledge in areas where knowledge shouldn't really be required (you shouldn't have to understand how GTK and GNOME work to use a system for Postfix, LDAP and Apache administration without undue confusion).

In my mind the easiest solution is to tell GTK to use the Human theme as a fallback if the requested user theme cannot be found. At least that way, the user will see a familiar theme in front of them.

I don't think allowing root applications to scan user directories for themes is a wise idea and I suspect the patch would never make it past the relevant maintainers.

Since the user has root access anyway, allowing to use the user's theme is not a problem. There are certainly many other holes like this in GTK, and the only way to avoid them is to not run GTK applications as root, ever.
For one, the application does apply the users theme settings, it just searches for the theme in the wrong place. If you want this kind of security the application should *not* use the user's settings.

However, there is one more problem. If you su to an user other than root the ~/.themes might not be accessible. Anybody doing that must do it manually, though. So they should also know how to make their theme available.

How about this for a solution:

Situation:
The user changes her theme to a non-standard one installed by downloading an archive file and installing it with GNOME's appearance properties application.

Problem:
Applications launched by the user via. a "sudo" or "gksu" command do not reflect the user's theme.

Explanation:
The root user may not have had the user's theme selected, had their own theme selected by an administrator using the root account graphically (which as far as I know is not a good idea), or had the user's theme selected but cannot find it because it is not in their .themes directory.

Solution:
Allow gksu to change environment in such a way that the program launched by gksu has the user's theme. Whether this is by changing environment variables to flag the GTK program, pointing the program to a different gconf configuration, or something else (hopefully decided by someone with a much deeper knowledge of GNOME and GTK than myself), it should not change GTK or GNOME properties for any other root-run program but the one launched by gksu.

Rationale:
Modifying sudo to fix a minor gtk appearance bug seems like a very bad idea. However, gksu is gtk-based and as such should integrate as perfectly as possible into that environment. Also, this solution would allow the use cases where the root account is using that account graphically in GNOME/GTK to act correctly (i.e. run using the root's theme rather than the user's theme), if implemented correctly.

What is the general consensus on this solution?

For me, two best solutions would be:

a) Advising a user that automatically installed themes affect only to user account and won't be selected for administrator accounts.

b) creating an option in the appearance configuration dialog that lets user install a theme globally and select it (obviously this button will launch a gksu dialog asking for root password)... "install to the system" or something like this...

Thanks for your interest!!!

the policykit use in hardy means that admin tools are running as user now

There's a lot of confusion here. Themes should not be installed globally, though I think they should all be available globallly after installation.

I agree that it is good to have a different theme for root actions - so I would like to launch gksu appearances to set my sudo theme, better option would be to have the option in the 'Appearances' window to 'relaunch as root'.

I send the menu launcher to make a launcher on desktop, and put 'gksu' in front of the command. It launches, and it works - it has a different theme (metal instead of 'Moku') and looks altogether more authoritive than friendly wood, being steel.

The trouble is that Root isn't looking to it's own folder for gksudo applications - it will look at the /usr folder and take the theme from there which is shared. Unless the desktop is launched as root, then sudo apps won't take the theme set by Appearances run as root. If they can find the theme in shared folders, they'll wear the same skin as the user.

I would like to set a root theme to apply to my sudo apps.

Please don't confuse this as a feature. The bug here is simply that
applications are being run as root.

Changing to invalid - this bug only affects small group of users that download and install themes by themselves, therefore it's not a papercut.

Mmmmh, i do think it's a papercut. I install ubuntu for a lot of people, and lots of them complaint about the theme/icons doesn't appears for applications that runs for root (on gksu), so i have to do a sudo cp -R ./icons /usr/share/icons and that stuff all the time (or run themes on normal users, and then gksu themes).

This is a typical papercut, and trying to give a better eyecandy on ubuntu is a must-go, as is intended for karmic+1 ;-)

Thanks.

Any GTK app running as root is a total face gash. It should not be happening
under any circumstances. Let's fix that problem instead.

i dont know if this is the same thing, but to use the theme of the current user in your root system is done by :

sudo ln -s ~/.themes /root/.themes
sudo ln -s ~/.icons /root/.icons
sudo ln -s ~/.fonts /root/.fonts

now i would like to know how i could add an new user, and use the theme that i use as normal user, without it defaulting to the human theme...?

Please delete this comment if its not on topic ...

The present behavior is actually a good feature.
The user can set a different theme/icon set for the root user, this is useful when working with several windows and to quickly realize that the window has root privileges. Especially when having the root windows open for a long time.

That's no reason to not fix this bug, as I'm pretty sure GTK explicitly
whinges about being run as root.

So... I see this isn't getting into Karmic either.

The present behaviour is NOT a good feature. There is no value whatsoever in having the user experience go from smooth to crap just because the distro has decided to escallate a program to root prividledges. The fact that in Ubuntu you have to [graphically or otherwise] provide [sudo] your password in response to a "you need to have administrator priviledges to do $this" repeatedly is, I should think, more than sufficient to warn the user they are escallating. Making (eg) synptic look terrible afterwards as a "further warning" is just ridiculous

AfC

I just modified a theme recently, and put my own version in ~/.themes. The day after, I discovered the issue with synaptic. I wanted to create a bug about it to help improve the distro on that little issue, and I'm amazed by the fact that it has been done 4 years before, and by the amount of misunderstandings in this thread, for a problem that in the end is not that complicated.

As a few posts point out, it is not just a bug, but a matter of architecture. Therefore I suppose the decision is to be taken by people with a high enough system view. I don't claim to be part of these. Anyway, since I'm here, I might as well express an opinion.

Clearly, the current situation just sucks. And using human theme by default instead of good old gtk default is definitely not an answer.

Suggestion : A solution could be to add a graphical way (a new button) in the theme manager, to allow a user to install a theme system-wide after entering his password. The theme would then be copied into /usr/share/themes.

This way, special users (the ones that use root privileges) would be able to have their favourite theme used when using root applications. And normal users would not be able to install themes globally but anyway they don't have to, they are not concerned.

And no need, then, for symlinks or /usr/share/themes permissions modification.

Incidentally, doing this would provide the admins with a nice GUI to manage the themes and install them globally. Which wouldn't be such a luxury considering the fact that quite a lot of users are using ubuntu on their own home desktop and therefore admins.

I believe this would respect current sudo philosophy. But again I may not have enough insight to judge.

Assuming my suggestion above is not stupid.

Rather than saying that it is a bug that affects sudo or gksudo commands, we could change it into a feature requests that affects whatever are the graphical applications that manage the gtk themes on (x)ubuntu distributions. Or that the system lacks such an application.

This would be a step into the direction of designing a nice GUI as described above.

This would please those who think here (and they are right) that gksuso and such are low level applications that shouldn't be modified for such a trivial issue.

I think it's a UX bug and not really specific to gksudo or gtk+.

it is now 2010

this still has not been resolved

we are still in workaround-land

five years later

nice

it is now 2011, still not resolved.
for me, this bug has been triggered by this workaround around the too dark inactive menu item text in ambiance: http://askubuntu.com/questions/7561/how-to-change-the-color-of-menu-text

gksu is a hack. fix your applications.

On 6 May 2011 09:11, "Christoph Buchner" <email address hidden> wrote:

it is now 2011, still not resolved.
for me, this bug has been triggered by this workaround around the too dark
inactive menu item text in ambiance:
http://askubuntu.com/questions/7561/how-to-change-the-color-of-menu-text

--

You received this bug notification because you are a direct subscriber
of a duplicate bug (201534).
...
Title:

applications run through gksu cannot use themes in ~/.themes
To unsubscribe from this bug, go to:
https://bugs.launchpad.net/gksu/+bug/24280/+subscribe

I'm out of the office until 1st August.

On 6 May 2011, at 09:03, Christoph Buchner <email address hidden>
wrote:

> it is now 2011, still not resolved.
> for me, this bug has been triggered by this workaround around the
> too dark inactive menu item text in ambiance: http://askubuntu.com/questions/7561/how-to-change-the-color-of-menu-text
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/24280
>
> Title:
>  applications run through gksu cannot use themes in ~/.themes
>
> Status in The "GKSu" Gnome Frontend for "su":
>  Invalid
> Status in One Hundred Paper Cuts:
>  Invalid
> Status in “gksu” package in Ubuntu:
>  Confirmed
>
> Bug description:
>  The user interface of the theme manager does not make clear that it
>  can only install themes for the current user. Furthermore it does not
>  provide an option to install themes system wide. This very often
> leads
>  to bug results like this one:
>
>  Scenario:
>
>  A) User finds spiffy (or totally hideous) theme online and loves it.
>
>  B) User installs theme and uses it.
>
>  C) User selects any sudo-required admin app and is greeted with the
> default GTK
>  theme.
>
>
>  Solutions:
>
>  1) Live with it and wait until GTK uses a nice default theme
> (dapper + 1 if
>  we're lucky?).  Is this even good enough?
>
>  2) Stick the user $HOME/.themes directories into whatever path gtk
> uses to find
>  themes so the admin apps match the user apps no matter what awful
> creation the
>  user might be imposing upon [him|her]self.
>
>  3) Be smart enough to know if a theme is not available and fallback
> to the
>  default Human theme or something along those lines... basically
> just do anything
>  to avoid showing it un-themed.
>
>  4) Create a new theme specifically for use with apps that require
> sudo priv.
>  Use this theme at all times.  Maybe make it an /etc setting
> somewhere for people
>  that can't stand it and "must" change it for whatever reason.

Next month this bug will celebrate its seventh birthday!

Please fix the theme issue for gksu / sudo / elevated-privilege applications. Make GTK check for themes in the user's home directory, make gksu create a temporary symlink to the user's theme directory, I don't know, but in seven years surely someone could have come up with a solution.

They sort of did solve this bug. Rather than using gksu and running applications as an administrator, most applications that require "administrator-privileges" use a separate background application. Those applications have a "unlock" button.

Most applications have already been upgraded to this new approach, except for a few, like the update-manager. I think the plan, there, is to integrate it, within the USC.

I'm not an ubuntu-dev, but it seems they were aiming to fix many problems at once, using this new architecture, but it's more work, so it takes a bit longer, but when it's done, not just this bug, but many others can be closed. It's a different trade-off.

On the other hand, the customization, and manual themes in general, is taking a back-seat to other priorities.

I don't think this bug should be fixed. If you run application *as* root, the application should use root's theme settings but not the caller's.