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

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)

by Paul Chitescu

On Monday 30 November 2009 05:51:35 pm Alexandre Julliard wrote: > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > > } > > > > - *service->service_entry = new_entry; > > - save_service_config(service->service_entry); > > + err = save_service_config(&new_entry); > > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > > service_unlock(service->service_entry); > > This can't work, the strings have been freed already. > > -- > Alexandre Julliard > julliard(a)winehq.org Oh, I see it now. This means that currently the old strings are leaked if the new strings provided are NULL. I'll write a replacement that will free the all the strings of either old entry or new entry at the end (depending if save_service_config succeeds or not).

Nov. 30, 2009

today's git broke winetricks gecko :-(

by Joerg-Cyril.Hoehle＠t-systems.com

Jacek Caban wrote: >You should understand, that we don't want users to have problems due to >*lack* of Gecko. Fair enough. > Instead you just said that >you pollute winetest results with your bad configuration. Are you being rude or what? I've not been polluting anything. I've -- quite simply -- used for years a (seemingly) perfectly reasonable and supported[*] configuration, namely a Wine without Gecko. Austin English too has provided "ae-nogecko" test data for ages. [*] "you can avoid problems" in WineGecko is not at all the same as "It is highly recommended that you install Gecko in order to avoid mysterious failures even with applications that do not seem to have anything to do at all with HTML. That's not how Windows works." Well, as I said earlier, my next Mac testdata will use Gecko. I'd appreciate if the WineGecko page could be augmented with a recommendation about how to add Gecko to an existing .wine. I'm used to rm .wine/.update-timestamp wine winecfg Is that fine? Regards, Jörg Höhle.

Nov. 30, 2009

Re: services.exe: Reduce Registry access to KEY_READ or MAXIMUM_ALLOWED wherever possible (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > @@ -569,11 +569,11 @@ DWORD svcctl_ChangeServiceConfigW( > new_entry.config.lpDisplayName = strdupW(lpDisplayName); > } > > - *service->service_entry = new_entry; > - save_service_config(service->service_entry); > + err = save_service_config(&new_entry); > + if (ERROR_SUCCESS == err) *service->service_entry = new_entry; > service_unlock(service->service_entry); This can't work, the strings have been freed already. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? Yes, the right approach to multiuser is to have wineserver and system processes run as root, and normal processes run as different users. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009

Fedora users, please test mci patch about time-out/hanging machine

by Joerg-Cyril.Hoehle＠t-systems.com

Michael, >> So the cause of random mci time-out on test.winehq may as >well lay elsewhere. >Like in PulseAudio? That may well be. PA in F11 made sound be more >broken in Wine. Is that your own experience or other people's reports? My experience with PA in Ubuntu Intrepid -- it's not the newest Ubuntu at all -- is that it has been stable for several month now, to a point where I regularly forget to run "pactl exit" to stop it every time I log into Gnome as I did half a year ago. Lastly, Wine has performed equally well in a PA, ALSA or OSS setting AFAICT. It's long ago that PA caused known bugs such as stuttering (in Hardy and Intrepid); they must have been fixed by a combination of changes in Wine and perhaps Ubuntu updates(?). Of course, YMMV. One issue remains in Intrepid: Because Timidity was not modified for PulseAudio[*], it grabs the ALSA device when it starts, causing all subsequent PA clients to loose access to sound. So it is still advisable to issue "pactl exit" to let Wine (and Timidity) share ALSA well. Regards, Jörg Höhle [*] or because PA was badly integrated? Why should every sound using package be modified when something like PA jumps into a distribution?!?

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Paul Chitescu

On Monday 30 November 2009 05:16:34 pm Paul Chitescu wrote: > On Monday 30 November 2009 04:02:03 pm you wrote: > > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > > > Changelog: > > > wineserver: Added support for read/only Registry, similar to > > > unprivileged users > > > > > > Rationale: > > > This is a first step towards implementing shared wine prefixes > with > > > most users being unprivileged and a single Administrator (power user, > etc.) > > > capable of installing programs. > > > > I don't think it's a step in the right direction. What you need is > > proper access control with security descriptors, like we have for other > > objects. A single read-only bit cannot be extended to support this. > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > > In the filesystem we use as backend for Registry all we can tell is if we can > write to it or not so in the end one bit is all that's relevant (except if > it's completely unreadable when wine should abort). > > No matter what an user does it cannot change that. We don't want a wine > service running as root trying to replicate Windows access rights on the > native system, do we? > > ACLs would require at least some mapping between wine users and native system > users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to > Registry if it's read only so that one bit should suffice. > > > Paul I should add that we can emulate the behavior of a non-admin user by including it in the Administrators group only if it can open for writing HKLM\Software or similar. This will make programs happier even if they still can't write to the Registry.

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Paul Chitescu

On Monday 30 November 2009 04:02:03 pm you wrote: > Paul Chitescu <paulc(a)voip.null.ro> writes: > > > Changelog: > > wineserver: Added support for read/only Registry, similar to > > unprivileged users > > > > Rationale: > > This is a first step towards implementing shared wine prefixes with > > most users being unprivileged and a single Administrator (power user, etc.) > > capable of installing programs. > > I don't think it's a step in the right direction. What you need is > proper access control with security descriptors, like we have for other > objects. A single read-only bit cannot be extended to support this. > > -- > Alexandre Julliard > julliard(a)winehq.org In the filesystem we use as backend for Registry all we can tell is if we can write to it or not so in the end one bit is all that's relevant (except if it's completely unreadable when wine should abort). No matter what an user does it cannot change that. We don't want a wine service running as root trying to replicate Windows access rights on the native system, do we? ACLs would require at least some mapping between wine users and native system users. And anyway, even SYSTEM or NT AUTHORITY would be unable to write to Registry if it's read only so that one bit should suffice. Paul

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Nikolay Sivov

Ilya Shpigor wrote: >> Or course you can, format a string every time contents change and store >> it with SetWindowText(). WM_GETTEXT >> will work through default procedure (I've done it that way for IPAddress >> control). >> > > This is good idea, but SetWindowText just send the WM_SETTEXT message. Your > patch "comctl32/datetime: Block WM_SETTEXT message" don't allow to do it. > Ah, forgot about it, sorry. Now I think your way is good enough, maybe WM_SETTEXT is still forwarded to default procedure and WM_GETTEXT not, I don't know. >> Anyway GetWindowText should work, and Wine's implementation uses >> WM_GETTEXT only for same process windows, >> so you shouldn't override default handling for this message. >> > > This possible to test: is the datetime window procedure process WM_GETTEXT? > This message must be send to control directly and be processed through > CallWindowProc with DefWindowProc parameter. Is this test give right results? > It's possible but such test will tell nothing, WM_GETTEXT definitely works for this control class and returns current content. Blocked WM_SETTEXT makes me think that WM_GETTEXT is overridden as you've done. To test that you could subclass control, catch WM_GETTEXT in subclass proc and forward it to default procedure directly bypassing control handling. If it returns nothing or some creation time passed text then your patch is ok. All of that comes to be extra testing not related to directly visible control behavior, treat this as additional checks.

Nov. 30, 2009

Re: comctl32: Implementation the WM_GETTEXT processing of datetime control

by Ilya Shpigor

> Or course you can, format a string every time contents change and store > it with SetWindowText(). WM_GETTEXT > will work through default procedure (I've done it that way for IPAddress > control). This is good idea, but SetWindowText just send the WM_SETTEXT message. Your patch "comctl32/datetime: Block WM_SETTEXT message" don't allow to do it. > Anyway GetWindowText should work, and Wine's implementation uses > WM_GETTEXT only for same process windows, > so you shouldn't override default handling for this message. This possible to test: is the datetime window procedure process WM_GETTEXT? This message must be send to control directly and be processed through CallWindowProc with DefWindowProc parameter. Is this test give right results? > P.S. Also don't forget comments regarding tests part. The second try of test have been send. -- Best regards, Ilya Shpigor.

Nov. 30, 2009

Re: wineserver: Added support for read/only Registry, similar to unprivileged users (try 2)

by Alexandre Julliard

Paul Chitescu <paulc(a)voip.null.ro> writes: > Changelog: > wineserver: Added support for read/only Registry, similar to > unprivileged users > > Rationale: > This is a first step towards implementing shared wine prefixes with > most users being unprivileged and a single Administrator (power user, etc.) > capable of installing programs. I don't think it's a step in the right direction. What you need is proper access control with security descriptors, like we have for other objects. A single read-only bit cannot be extended to support this. -- Alexandre Julliard julliard(a)winehq.org

Nov. 30, 2009