On 04/03/09 20:57, John Rice wrote:
[email protected] wrote:
The fix is to reset the HOME environment variable to /root if we
are being run with uid of 0 to avoid dbus attempting to write a
file on NFS mounted filesystem, for which it does not have
permissions.
Is this really the right way of handling this? It seems very strange
for a user running an application to end up modifying root's home
directory.
David this is just a hack, if you look at the discussion thread in
the community, its a mess and the simple answer is that apps in
Gnome using gconf at the minute are suffering a range of issues and
all having to find their own custom solutions. The Home dir is being
set jsut for the running PM process, so providing PM is working fine
and there are no other issues we should be fine. This will require
more testing to make sure it all works satisfactorily and has no
unexpected side effects.
So we can put this in, or live without the gconf support if you have
an NFS mounted Home dir :( The other suggestion of using dbus-launch
leaves zombie dbus processes hanging around so this is not a viable
solution.
What about using something in /tmp or /var/tmp (the latter, to my
disappointment, seems to be heavily used by GNOME to store lots of
things! :)
Well we could create a unique tmp dir in /tmp and set HOME to that
(/tmp/<unique_tmp_dir>) so it would be unique for that session,
perhaps better than setting the HOME to /root, at least feels less
dangerous :)
The application is running as root so using root's home directory seems
natural. The file which is created is a file in $HOME/.dbus/session-bus.
Padraig
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
