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

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

by Vincent Povirk

> $ wine setup.exe # program doesn't work/error about admin rights/etc. > $ sudo wine setup.exe > wine: '/home/user/.wine' is not owned by you, refusing to create a > configuration directory there > $ sudo su > # wine setup.exe Ok, if I understand you, one of the following things happens after that: * The program fails in the same way. I don't think that's really a problem. * The program succeeds because it really did need to be root. That's not really a problem either, unless we can provide what the program needs without being root. * The program succeeds because root's .wine directory is pristine. That's bad. The user should just be running a new WINEPREFIX instead of root. Simply putting up an obstacle without suggesting an alternative won't help anyone. So we should be looking for a way to encourage users to try a new WINEPREFIX before trying things as root?

Feb. 11, 2009

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

by Austin English

On Wed, Feb 11, 2009 at 11:02 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: >> No we don't want Wine to function in those cases, and it is part of the >> ownership test already. > > wine: '/home/sudotest' is not owned by you, refusing to create a > configuration directory there > > So it is. Well then, there's no need for an additional warning as far > as I'm concerned. The problem is people doing: $ wine setup.exe # program doesn't work/error about admin rights/etc. $ sudo wine setup.exe wine: '/home/user/.wine' is not owned by you, refusing to create a configuration directory there $ sudo su # wine setup.exe I filed bug 17337 (http://bugs.winehq.org/show_bug.cgi?id=17337) for this. If you'd like to take a try at it, please do, not sure when I'll have time to do so. > When was this added? http://source.winehq.org/git/wine.git/?a=commitdiff;h=3e8532779f1f93619f368… -- -Austin

Feb. 11, 2009

Re: An idea for the appdb

by Tim Schwartz

On Wed, Feb 11, 2009 at 8:58 AM, <wine-devel-request(a)winehq.org> wrote: > Send wine-devel mailing list submissions to > wine-devel(a)winehq.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.org/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.org > > You can reach the person managing the list at > wine-devel-owner(a)winehq.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Message: 2 > Date: Wed, 11 Feb 2009 23:57:48 +1100 > From: Ben Klein <shacklein(a)gmail.com> > Subject: Re: An idea for the appdb > To: Luke Benstead <kazade(a)gmail.com> > Cc: Wine Devel <wine-devel(a)winehq.org> > Message-ID: > <d7e40be30902110457t3d84c396ibfd264aead12d6e9(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >> 2009/2/11 Ben Klein <shacklein(a)gmail.com>: >>> 2009/2/11 Luke Benstead <kazade(a)gmail.com>: >>>> My idea is that the appdb should allow for people to associate a list >>>> of checksums with an application version. For example, WoW might have >>>> the checksum for the setup program and the game's executable, >>>> associated with the appdb entry. The other extension to the appdb >>>> would be to allow a way to programmatically retrieve information on an >>>> application's rating etc. by going to a certain address (e.g. >>>> http://appdb.winehq.org/getAppInfoFromChecksum.php?checksum=ac2b3f5928cba...) >>>> which would return the info in XML or some other format. >>> >>> You've clearly put quite some thought into this, which is highly >>> commendable. However, I would personally be against such a move, as it >>> would put a lot of extra load on AppDB (in terms of network >>> bandwidth). I'm also not too keen about something that retrieves data >>> from the net every time you run an app. It's too easy for people to >>> mistake it for spyware. >> >> Hmm.. I see your point. However would it really use that much >> bandwidth? I mean, any sane implementation of the functionality I >> described would only display the dialog the first time that >> application was used. Retrieving a tiny xml file is surely less >> bandwidth than browsing the appdb for the application (granted it will >> happen more often than people browsing the site but I still don't >> think it's masses of bandwidth). I can also see what you mean about >> spyware, but other apps retrieve stuff from the web if there is a >> connection (CDDB, and album covers are two examples). > > A request to AppDB would be at least once per user, application > version and Wine version combination. Given the number of people using > Wine, this would almost certainly be a massive load increase on AppDB, > it would repeat roughly every 2 weeks (when new releases come out), > and possibly even bring AppDB down as a worst-case scenario. What about packaging the latest appdb information with each release? Tim Schwartz Sanity Internet tim(a)sanityinternet.com

Feb. 11, 2009

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

by Vincent Povirk

> No we don't want Wine to function in those cases, and it is part of the > ownership test already. wine: '/home/sudotest' is not owned by you, refusing to create a configuration directory there So it is. Well then, there's no need for an additional warning as far as I'm concerned. When was this added?

Feb. 11, 2009

Re: An idea for the appdb

by Gert van den Berg

On Wed, Feb 11, 2009 at 2:24 PM, Luke Benstead <kazade(a)gmail.com> wrote: > I can also see what you mean about > spyware, but other apps retrieve stuff from the web if there is a > connection (CDDB, and album covers are two examples). > Wine transmitting every application I run to someone else would be rather worrying... It should rather be opt-in. Such as "Wine has detected that it is the first time you run this application, do you want to check AppDb for more information (Yes/No/Ask again/Never ask for any application)" It must be easy to disable globally as well... It might have some other uses as well such as "A newer version of the application works better", etc. I might be handy to allow automatic submission of test data to AppDb (which IMHO might be more useful than just retrieving...), which should automatically include the Wine executables' checksums + version, distro info (if accessible from lsb-release, parts of the uname output & kernel checksum, which might be used to detect the distro), kernel version, cpu architecture, X server name and version, graphics driver name and version, DLL overrides, etc. This might help modified wine versions and the level of tweaks to be detected by AppDb automatically. (There should be a very specific opt-in process for this data's submission though, such as letting the user manually upload a file with this data and fully disclosing the file's contents) This kind of data can be handy for bug reports as well. Gert

Feb. 11, 2009

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

by Francois Gouget

On Tue, 10 Feb 2009, Andrew Talbot wrote: [...] > There are also many calls to realloc() - a function with complexities of its > own - and other functions with "realloc" in their name. Good point. Here are the ones I noticed: dlls/rsaenh/mpi.c:3668: if ((tmp = realloc (a->dp, sizeof (mp_digit) * a->used)) == NULL) { dlls/rsaenh/mpi.c:72: tmp = realloc (a->dp, sizeof (mp_digit) * size); dlls/twain_32/dsm_ctrl.c:87: devices = realloc(devices, sizeof(devices[0])*(nrdevices+1)); dlls/advapi32/tests/registry.c:55: if ((ret = realloc( list[idx], size ))) list[idx] = ret; dlls/ddraw/tests/ddrawmodes.c:97: modes = realloc(modes, (modes_size *= 2) * sizeof(DDSURFACEDESC)); dlls/mstask/tests/task.c:41: if ((ret = realloc(list[idx], size))) dlls/oleaut32/tests/tmarshal.c:59: if ((ret = realloc( list[idx], size ))) list[idx] = ret; dlls/userenv/tests/userenv.c:54: if ((ret = realloc( list[idx], size ))) list[idx] = ret; And we even have two calls to calloc()! dlls/winedos/int33.c:267: MCALLDATA *data = calloc(1,sizeof(MCALLDATA)); dlls/winedos/devices.c:137: hdr_ptr = calloc(1,sizeof(void *)+extra); -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

Feb. 11, 2009

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

by James Mckenzie

Steve Brown <sbrown7(a)umbc.edu> wrote: > >On Tue, 10 Feb 2009, Vitaliy Margolen wrote: > >> 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.... > >No, the whole point of using sudo is that it removes the necessity of >anyone other than root knowing the root password. If OpenSuSE's default >config requires anyone that needs elevated privileges to know the root >password, it is broken. Using a properly configured sudo, the non-root >users are allowed to execute a (possibly limited) number of commands with >root privileges, but authenticating using their OWN password. > The password method of invoking sudo depends on the UNIX release and the security policy in effect. I've used SUDOUSERS to set who has access to this, used a special password. It is not good security policy to use root's password, unless login as root is completely disabled, as it is with the Mac (it takes six steps to enable root login and Apple advises that this is not necessary.) However, under no circumstances, should a non-admin user run any Wine application as a super-user through this method. It causes problems as files are created with root's credentials and this causes confusion with some new users. Experts (supposedly) know how to fix this. Running Wine as root should bring up a warning message, in Windows format (that is with the warning icon) advising users that they are running Wine as root and that applications installed and files created will not be available to all users (as they would be in some versions of Windows(TM)). I think this is the purpose of the original request. I do support this as a one-time only warning. Permission to run Wine applications as sudo should remain disabled as some users know of this function and use it to get around running and having root's information. James McKenzie

Feb. 11, 2009

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

by Marcus Meissner

On Wed, Feb 11, 2009 at 09:35:26AM -0500, Steve Brown wrote: > On Tue, 10 Feb 2009, Vitaliy Margolen wrote: > > > 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.... > > No, the whole point of using sudo is that it removes the necessity of > anyone other than root knowing the root password. If OpenSuSE's default > config requires anyone that needs elevated privileges to know the root > password, it is broken. Using a properly configured sudo, the non-root > users are allowed to execute a (possibly limited) number of commands with > root privileges, but authenticating using their OWN password. sudo has more features that are good ... like keeping authentication for some time or specific roles. Thats why openSUSE keeps it secure this way (by using the root password). You can of course change this for yourself. This has been discussed to dead for openSUSE already, but if you want to discuss this further, move it to opensuse-security(a)opensuse.org. Ciao, Marcus

Feb. 11, 2009

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

by Steve Brown

On Tue, 10 Feb 2009, Vitaliy Margolen wrote: > 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.... No, the whole point of using sudo is that it removes the necessity of anyone other than root knowing the root password. If OpenSuSE's default config requires anyone that needs elevated privileges to know the root password, it is broken. Using a properly configured sudo, the non-root users are allowed to execute a (possibly limited) number of commands with root privileges, but authenticating using their OWN password. Steve Brown sbrown7(a)umbc.edu

Feb. 11, 2009

Re: imm32: Make space for a 64bit pointer in the IMM window.

by Aric Stewart

Ok digging into my IME documentation I see this: "The cbWndExtra of the UI class has to be 2 * sizeof(LONG). The purpose of this WndExtra is defined by the system (for example, IMMGWL_IMC and IMMGWL_PRIVATE)." So any IME developer is properly reserving 64 bits already. Which means my concern is not valid. -aric Michael Stefaniuc wrote: > Aric Stewart wrote: >> I am not a 64 bit expert but i do not think this is going to work. >> >> ddk/imm.h is a Microsoft header so IMEs and programs compiled with the >> original header will not have the expanded space. > They will as the Microsoft header has the exact same change as I did in > this patch. It's not directly in imm.h but in immdev.h; our imm.h header > would need to be split for "full compatibility" with the Microsoft DDK > headers but that's something for an other patch. > > bye > michael > >> To fix this properly (I assume you are trying to support 64 bit) is that >> we will probibly have to store a handle instead of a pointer in the LONG >> value. The IME is expecting a HIMC in that value. >> >> Which leads to a more general question. What is the suggested way to >> generate handles like that? Working toward 64 bit means that everywhere >> that we are using pointers as LONG handles is going to have problems. >> >> -aric >> >> Michael Stefaniuc wrote: >>> --- >>> Next try at fixing this problem. I didn't find any other place where >>> IMMGWL_IMC is used and the window classes are not my area of expertise. >>> >>> >>> >>> dlls/imm32/imm.c | 2 +- >>> dlls/winex11.drv/ime.c | 2 +- >>> include/ddk/imm.h | 2 +- >>> 3 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c >>> index 14178c3..bb50e5e 100644 >>> --- a/dlls/imm32/imm.c >>> +++ b/dlls/imm32/imm.c >>> @@ -2291,7 +2291,7 @@ BOOL WINAPI ImmSetOpenStatus(HIMC hIMC, BOOL fOpen) >>> data->imeWnd = CreateWindowExW( WS_EX_TOOLWINDOW, >>> data->immKbd->imeClassName, NULL, WS_POPUP, 0, 0, >>> 1, 1, 0, >>> 0, data->immKbd->hIME, 0); >>> - SetWindowLongW(data->imeWnd, IMMGWL_IMC, (LONG)data); >>> + SetWindowLongPtrW(data->imeWnd, IMMGWL_IMC, (LONG_PTR)data); >>> IMM_GetThreadData()->hwndDefault = data->imeWnd; >>> } >>> >>> diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c >>> index 87d4faa..6d083d1 100644 >>> --- a/dlls/winex11.drv/ime.c >>> +++ b/dlls/winex11.drv/ime.c >>> @@ -1326,7 +1326,7 @@ static LRESULT WINAPI IME_WindowProc(HWND hwnd, >>> UINT msg, WPARAM wParam, >>> * messages. >>> */ >>> >>> - hIMC = (HIMC)GetWindowLongW(hwnd,IMMGWL_IMC); >>> + hIMC = (HIMC)GetWindowLongPtrW(hwnd,IMMGWL_IMC); >>> if (!hIMC) >>> hIMC = RealIMC(FROM_X11); >>> >>> diff --git a/include/ddk/imm.h b/include/ddk/imm.h >>> index 6e4d42f..bc9617e 100644 >>> --- a/include/ddk/imm.h >>> +++ b/include/ddk/imm.h >>> @@ -114,7 +114,7 @@ HIMCC WINAPI ImmReSizeIMCC(HIMCC, DWORD); >>> DWORD WINAPI ImmGetIMCCSize(HIMCC); >>> >>> #define IMMGWL_IMC 0 >>> -#define IMMGWL_PRIVATE (sizeof(LONG)) >>> +#define IMMGWL_PRIVATE (sizeof(LONG_PTR)) >>> >>> /* IME Property bits */ >>> #define IME_PROP_END_UNLOAD 0x0001 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >

Feb. 11, 2009