ntdll: add a warning about running wine as root (resend)

Ben Klein shacklein at gmail.com
Tue Feb 10 20:46:44 CST 2009


2009/2/10 Francois Gouget <fgouget at free.fr>:
> On Tue, 10 Feb 2009, Ben Klein wrote:
> [...]
>> > Application tried to create a window, but no driver could be loaded.
>> > Make sure that your X server is running and that $DISPLAY is set correctly.
>> Interesting. xauth problem. Again, I'd be surprised if this happened
>> with sudo. Not so surprised if it happened with "su -".
>
> X access will very often be broken after a sudo or an su (e.g. Debian).
> In fact I believe it will only work on distributions which install
> special PAM packages. For all others you should use gksu, kdesu or sux.

I'm on Debian and I don't have trouble with X access when using su.
"su -" is another matter entirely.

I don't know about X access with sudo (because I've strictly
restricted my sudo to only run certain commands. I like my root user
:) ), but I'd imagine it'd work because $HOME is not overridden, so
the sudo'd program would be using the original user's ~/.xauth file.
Also, $DISPLAY would be set correctly.

2009/2/11 Vitaliy Margolen <wine-devel at kievinfo.com>:
> Alexandre Julliard wrote:
>> Vitaliy Margolen <wine-devel at kievinfo.com> writes:
>>> vitaliy at dragon:~ $export WINEPREFIX=~/.wine-root
>>> vitaliy at dragon:~ $sudo wine winecfg
>>> root's password:
>>> wine: created the configuration directory '/root/.wine'
>>
>> As you can see it's creating a new prefix under /root, so it's not
>> messing up the user's prefix. That's perfectly fine.
>>
> That part worked you are correct.
>
> However X11 part didn't (missing $DISPLAY). And even if $DISPLAY would be
> defined in this case all programs will be installed into root's env not
> user's. No menu entries, no desktop links no visible installed programs -
> big problem for noob users "where did my stuff go"?

This is not a problem with Wine, this is OpenSUSE breaking the
environment when sudo is called. Remember, Wine is not the only X11
app out there. Others will need $DISPLAY working!

Creating the wineprefix in root's home directory is expected behaviour
if $HOME is being overridden by preference in /etc/sudoers. Take it up
with the OpenSUSE guys if you don't like it.

2009/2/11 Alexandre Julliard <julliard at winehq.org>:
> Austin English <austinenglish at gmail.com> writes:
>
>> On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard
>> <julliard at winehq.org> wrote:
>>> No, a warning that will get drowned in a bunch of other fixmes is not
>>> useful.

Probably not, but I've seen a lot of newbies run "sudo winecfg"
because winecfg is a config tool, so they assume that it needs to be
run by root. In these cases, a message on console would likely be
visible, but I wouldn't be surprised if 90% of them still ignore it.
"Where's my pretty GUI? Why do I have to read all this boring text?",
that sort of thing.

>> We could make it a popup warning, again, only on first run.
>
> No, warning message boxes are just as useless, users have been
> conditioned by MS to click through without reading.

Not just useless, but very, very annoying :) Plenty of times, I've
started an app, gone to do some typing in another app, then a popup
appears as I'm typing which steals focus and I end up hitting "OK" on
it without being able to read it.

Also, if we do think about a message box, we have to think about how
to deliver it. It's been talked about before, and it can't be a Wine
dialog due to the amount of initialisation required before that point
(in particular, creating the wineprefix with wineboot). What options
does that leave us? Dialogs that depend on GTK, QT or KDE backends?
Choosing the "wrong one" here could annoy a lot of people, and for
proper integration it'd have to be chosen on a per-system basis, thus
supporting each method.

What about xmessage? Two words: it's ugly. It'd likely annoy new users
who suddenly see this ugly, old-styled dialog box in the middle of
their fancy new system, and people would probably ask why we can't use
something that better integrates with <insert DE here>.

> If you really want to prevent users from running as root you have to
> refuse to create the prefix and abort, and then make them jump through
> hoops to create it manually, by running wineboot explicitly or something
> like that.

This is kinda what I've been getting at with earlier posts. Should a
warning be a show-stopper? If so, this is a messy and unfriendly way
of doing things. Let's not be Windows Vista-style UAC here, let's
remember we're working on a Unix (or at least Unix-like) platform.



More information about the wine-devel mailing list