February 2009 - Wine-Devel - list.winehq.org

Re: Fully automated bisecting with "git bisect run" [LWN.net]

by Vincent Pelletier

On Wed, Feb 11, 2009 at 7:06 AM, Ben Klein <shacklein(a)gmail.com> wrote: > If I understand this correctly, this is only useful when the > regression is something that can be tested without human interaction. > This makes it virtually useless for Wine, as most regressions involve > loss of functionality some application. How hard would it be to create some record/replay feature in wine ? As ("If" ?) any user interaction has to go through wine code, there is potentially enough data to reproduce anything, if collected. Of course, just as Selenium and selenium scenario generators (like http://seleniumhq.org/projects/ide/ ), it's probably not enough to just record user action and replay it, there must be some filtering done to make the test more robust. Another use for such system would be (just like Selenium) automated testing. That could ease app maintainer life, I guess. Sure, this is non-trivial to write, probably quite intrusive (I have no knowledge of the code involved) and maybe non-trivial to use... -- Vincent Pelletier

Feb. 11, 2009

Re: Fully automated bisecting with "git bisect run" [LWN.net]

by Ben Klein

2009/2/11 nn <saturn_systems(a)yahoo.com>: > Fully automated bisecting with "git bisect run" [LWN.net] > http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ > > Would this be useful to add to the instructions on the wine wiki. > If I understand this correctly, this is only useful when the regression is something that can be tested without human interaction. This makes it virtually useless for Wine, as most regressions involve loss of functionality some application. However, it could theoretically be useful for regressions that cause a complete crash of the application early on. Would it be any faster? Probably not. Fewer commands to type, since you wouldn't need to run "git bisect bad" or "git bisect good" every time you test the app.

Feb. 11, 2009

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

by Ben Klein

2009/2/11 Vitaliy Margolen <wine-devel(a)kievinfo.com>: > Ben Klein wrote: >> 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! > This is something called security.... This is something called "nothing we have to worry about or address". It's not *expected* to work this way on your default OpenSUSE configuration. Note that security always comes at the cost of convenience. 2009/2/11 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: >> To abstract what you're saying here, you're suggesting to extend the >> wineprefix ownership test to include $HOME when $WINEPREFIX is not set >> and $HOME/.wine does not exist? >> >> That doesn't sounds like a bad idea to me. But I'm not so sure about >> specifically testing on UID=0 or SUDO_USER. > This specifically covers the one case that is broken for people who > maybe can't be expected to know any better: running wine for the first > time using sudo on ubuntu. I don't know why else $HOME would not be > owned by you, but I've been assuming we want Wine to function in those > cases (otherwise, we'd have added this test when we added the original > ownership test, right?). > > If a user's home directory will always be owned by the user in a > working Unix-like configuration, there's no need to test uid or > SUDO_USER. Um ... not sure what you mean here, but the problem comes when $HOME is not owned by $USER due to sudo. The default configuration of sudo on most distros is to use the calling user's $HOME. Vitaliy has demonstrated that this is not true for OpenSUSE, but as it has been discussed, OpenSUSE doesn't do anything unexpected as a result. (It's effectively the same as doing "su - -c wine" whatever.) My point is that enforcing the test only on UID is not a particularly neat way to do it, because you'd get the same permissions problems if "sudo -u otheruser" is used. Also, that the default wineprefix is in $HOME, which does not and should not involve a lookup in /etc/passwd for the home directory of the user indicated in $USER (or $SUDO_USER), since this has already been done when setting up the environment. So Wine really doesn't need to do special things with $SUDO_USER.

Feb. 11, 2009

Fully automated bisecting with "git bisect run" [LWN.net]

by nn

Fully automated bisecting with "git bisect run" [LWN.net] http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ Would this be useful to add to the instructions on the wine wiki. Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more

Feb. 11, 2009

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

by Vincent Povirk

> To abstract what you're saying here, you're suggesting to extend the > wineprefix ownership test to include $HOME when $WINEPREFIX is not set > and $HOME/.wine does not exist? > > That doesn't sounds like a bad idea to me. But I'm not so sure about > specifically testing on UID=0 or SUDO_USER. This specifically covers the one case that is broken for people who maybe can't be expected to know any better: running wine for the first time using sudo on ubuntu. I don't know why else $HOME would not be owned by you, but I've been assuming we want Wine to function in those cases (otherwise, we'd have added this test when we added the original ownership test, right?). If a user's home directory will always be owned by the user in a working Unix-like configuration, there's no need to test uid or SUDO_USER.

Feb. 11, 2009

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

by Vitaliy Margolen

Ben Klein wrote: > 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! This is something called security....

Feb. 11, 2009

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

by Ben Klein

2009/2/11 Vincent Povirk <madewokherd+8cd9(a)gmail.com>: > How about this: > > If uid = 0, SUDO_USER is set to a valid username, HOME is owned by > that user, and WINEPREFIX is not set, then refuse to start, printing a > message explaining the situation. > To abstract what you're saying here, you're suggesting to extend the wineprefix ownership test to include $HOME when $WINEPREFIX is not set and $HOME/.wine does not exist? That doesn't sounds like a bad idea to me. But I'm not so sure about specifically testing on UID=0 or SUDO_USER. > Perhaps the message can be something like > > You're running Wine for the first time as root, but your home > directory belongs to a normal user. Continuing would break Wine for > that user. > > You probably want to run Wine as a normal user. Wine does not need to > be root to install or run programs. > > > This will stop naive ubuntu users who think they need installers from > running Wine as root. Someone who has a legitimate need for root can > get around this by using a configuration that isn't broken. > > Vincent Povirk

Feb. 11, 2009

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

by Vincent Povirk

How about this: If uid = 0, SUDO_USER is set to a valid username, HOME is owned by that user, and WINEPREFIX is not set, then refuse to start, printing a message explaining the situation. Perhaps the message can be something like You're running Wine for the first time as root, but your home directory belongs to a normal user. Continuing would break Wine for that user. You probably want to run Wine as a normal user. Wine does not need to be root to install or run programs. This will stop naive ubuntu users who think they need installers from running Wine as root. Someone who has a legitimate need for root can get around this by using a configuration that isn't broken. Vincent Povirk

Feb. 11, 2009

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

by Ben Klein

2009/2/10 Francois Gouget <fgouget(a)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(a)kievinfo.com>: > Alexandre Julliard wrote: >> Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: >>> vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root >>> vitaliy(a)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(a)winehq.org>: > Austin English <austinenglish(a)gmail.com> writes: > >> On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard >> <julliard(a)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.

Feb. 11, 2009

Re: itss: Replace malloc() with HeapAlloc()

by Andrew Talbot

Francois Gouget wrote: > Also, for everyone's information, there's more calls to malloc() and > free(). There are also many calls to realloc() - a function with complexities of its own - and other functions with "realloc" in their name. -- Andy.

Feb. 10, 2009