This is the 163rd release of the Wine's kernel cousin publication. Its main goal is to give you something to read while I sit on beach in Mexico. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).
This week, 315 posts consumed 1066 K. There were 68 different contributors. 36 (52%) posted more than once. 20 (29%) posted last week too.
The top 5 posters of the week were:
|News: Interview Series Coming Soon||03/22/2003||Archive|
In conjunction with the newly redesigned WineHQ I'll be putting together an interview series with various Wine developers. This should be a fairly regular series and continue for a while. Look for new interviews every Tuesday on WineHQ. Make a note of that - if you read this update on Kernel Traffic you won't see it posted there.
The first one will be with Ove Kåven and with a little luck it'll appear this coming week. If you have any suggestions for future interviews let me know: question, topics, random thoughts, etc.
Jeremy Newman announced a makeover of the WineHQ site:
The hard parts are done. The site is live. Time to party like its 1999!
Thanks to all those who helped me with this undertaking. The new site was months in the making with most of the hard work in the last few days.
Dimi, when I see you, I owe you a beer.
Alright, back to my real job.
Jeremy did most of the work over the past week. A lot of people provided input, and a ton of suggestions were made. Here's a brief description of the threads discussion design considerations:
Great job Jeremy!
|Wine Downloads At SourceForge||03/23/2003||Archive|
Dimi Paun announced a repository of downloads available at SourceForge:
Some of you probably know that we had a wine project at SourceForge for a long time, but not much was done with it. Recently, we decided to transform it into our official download site:
It currently hosts source tarballs, support files, and binary packages for FreeBSD, RedHat, and Slackware. Check it out.
We invite comments, criticism, and/or praise :).
Eric Pouech wanted to know exactly what would be provided on SourceForge, I think we need to define clearly what is going to appear on winehq on one hand, and on SF on the other hand. I'm also worried about the sort of trouble we had to maintain all RPM/DEB/... available on winehq, so what's going to change (for good) on SF
Dimi explained it provided a place to download files from:
For now things are pretty clear:
|Making Wine Run With glibc 2.3||03/21/2003||Archive|
There's been some threads on wine-devel and IRC about making Wine work with the new kernels and glibc found in the latest Linux distributions. This has been covered in past issues (notably #155 and #156 ) , and so has the solution, however it wasn't that obvious. Hopefully by posting this again it'll prevent people from mailbombing the list as they upgrade their distribution and running into problems. Davide Giannotti asked:
Ok, i recently compiled and upgraded to glibc 3.2.1 (ed. note - he meant 2.3.1 ) and there's no way to make wine work. There's thread related bug. New Red Hat, SuSE and Mandrake will be shipped with this new version of glibc, so i think that's a serious bug.
Dan Kegel gave a nice summary of the appropriate workaround:
We were all quite concerned about it until somebody reported a workaround; see http://www.winehq.org/hypermail/wine-devel/2003/02/0260.html The workaround is to give the command
before running Wine (and probably before running configure, too). (This is documented in each distro's beta release notes, e.g. http://rpmfind.net/linux/redhat/beta/phoebe-3/en/os/i386/ ) Have you tried this yet?
The changes needed are deep. Alexandre has started on them, but given the workaround, it can probably wait a bit.
Sylvain Petreolle tested it and verified it worked. Kevin DeKorte had some problems until he grabbed a fresh copy from CVS. Also, you may want to note that RedHat has a boot-time option (nosysinfo ) that can be set to disable the new threading library.
|Wine & Services||03/19/2003||Archive|
Last week a thread about services popped up, but I didn't cover it. Again this week there was another. Lars Segerlund wrote:
Would it not be possible to launch wineserver to handle NT services ?
Thus if the user was logged in services would be running ( if he fx. had started wineserver in his .xsession file ).
I do realise that there are issues such as privileges and multiuser, but this would circumvent them would it not ?
I have looked at some of the other things people have written about services, but this looks doable.
Steven Edwards thought it would be possible, You might want to make a wrapper application like wine/programs/services. This program could then be started by wineserver and a config option if you want to try and run a NT service. I don't really see the point on running services under WINE unless you want to try and install AV software that loads as a service =)
Sylvain Petreolle didn't like the idea at all, dooooont do it ! even wineboot isn't started by the server !
Steven thought about it and remarked, I haven't been following how wineboot operates as I don't have a need for it under Mingw or Cygwin ATM. Sylvain is right you should look at the way wineboot and rpcss work under WINE and then implement services as such. It would be nice if you add a net command to wcmd so we can net stop service-name
Shachar Shemesh, wineboot author, gave some more input:
I guess you can blame the war for some of the delay with that (I live about where Saddam has aimed most of his scuds 12 years ago - I was more into launch probabilities and trying on gas masks than wineboot lately).
It basically boils down to this - wineserver has not started any synchronous wine utils in the past (the font generation is performed, as far as I can tell, in the server context itself), and the whole thing is taking time and patience to sort out. If all you want is asynchronous services starting, that's easy (I practically have the code lying around somewhere). If you want services to start halting other processes before they start - that's going to be tricker.
In any case, you can merge that right into wineboot itself. It currently has several command line options that control how it starts. One of the option is to do a full session startup, and another is to do just the pre-login startups (that one doesn't have a command line yet, but that's really simple). We can put services support there.
We can, but I don't recommend it. I think we should aim for Wine to have a simple RPM/Deb install. There are several implications to this simple statement. One of them is using a shared (unix) system wide directory structure (be it on a real or on a fake windows, doesn't really matter. Personally I think fake windows is the only thing that really matters). This, in turn, means that services should be started on system wide basis. Services also have a different set of permissions and users than the usual processes. In short - I think they belong in neither wrapper nor wineboot, but require a more specific solution.
Shachar also gave a link to a thread last October technical hurdles of implementing services. I didn't cover that one, but going back and re-reading it the issues are still relevant. Martin Wilck asked:
I have had a look at dlls/advapi/services.c and found that it is pretty incomplete. Can anybody tell what the current implementation is used for (are there any known programs starting services?)
In particular I'd like to know what people generally think about the usefulness of Services in Wine.
The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless. However it may be desirable to translate services into something useful on Unix, especially for winelib (it would be useful for the app I am trying to port).
Has there been a discussion yet how to set this up without compromising system security?
Greg Turner had a lot of ideas:
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root, they could just invoke their executable from an init script; that's more "service" like anyhow.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts. So, for example:
Now, we create "wineservices.exe", create sudo permissions on this for the appropriate users, and implement it very, very carefully.
Needless to say, this is a very sketchy proposition. It is "correct," from a certain perspective; it's also very, very likely that people will use it to create huge gaping security holes in their system, like basically allowing themselves to run arbitrary scripts as root with very little effort, and then, inevitably, wine will get a bad rap as a result.
I'm starting to lean towards the opinion that if these security and identity aspects start to be implemented, then wine should just have its own user database, kind of like samba. So, for example, we create a database that maps unix users onto wine users, with flexible percieved windows permissions within the wine sandbox, or, in server environments, wine maps unix accounts onto domain accounts from the server.
This way, a user could "be administrator" within wine, but not be root on their unix box. If we just thunk wine security down to unix security, we are ignoring a very important difference between Windows and UNIX: the vast majority of unix users don't run as root; whereas the majority of Windows users /do/ run as Administrator or some equivalent.
An example: wine users need to run installers. Installers, as often as not, need Administrator permissions. This isn't an issue right now because wine ignores security and tends to look like Windows 98 or lower, anyhow. As we move towards a 2000/XP-like implementation (this is inevitable and unavoidable IMO if we want wine to remain useful), things start to get really awkward. So, User X wants to run Adobe Acrobat installer (which more-or-less works with wine right now). But it's the future, and wine looks like W2K. So when the installer gets to the stuff about installing printer drivers, it fails, forcing the user to become root to do the install. But root doesn't even have a ~/.wine directory! And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
In short: wine has relied on unix security historically, and it's been good enough, because wine security / permissions implementations have been nonexistent or exceedingly simple. Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.
With the proper tools, this "just" becomes a packaging problem. However there is a lot of development work that needs to be done to make this feasible. Shachar gave some ideas how to tackle the permissions problems:
I think Wine should, and CAN, do without privelege escalation at all.
Let's look at some of the examples presented here. If we want to give a multi user Windows experience that is compatible with the multi-user Unix experience, our trust model must be comperable. My view of such a case is this: Wine is installed on the system. This means that there is a directory called "/usr/wine", inside of which you can find "/usr/wine/windows", "/usr/wine/Program Files" etc. Permissions on this directory are set according to the unix standard - i.e. - only admins.
Then again (assuming W2K compatibility) - you get "/usr/wine/Documents and Settings/dimi", that is a symlink to "/home/dimi/wine". It goes without saying that, as far as the Windows applications, "C:\Documents and Settings\dimi" is the directory, writable to the proper user.
Now, you need to be administrator to install a new program. Nothing new about that. If the admin want's to change that, she can set a group to the entire /usr/wine directory structure, and give that group write permission. There are still some security issues with this model. The wine server probably needs to be SUID to server everyone, etc. But still, that is a model that works. Besides, the server does not need to be SUID root, it can have a special user for that purpose. This is probably also required for registry access, if we want to enforce registry ACLs - we can't have a malicious user by pass the wine permissions by simply accessing the file directly, so the system registry file must not be readable by normal users (hence the need for suid on the server).
As for printer drivers, and services at large - there is a major question here of whether we wish Wine services to be able to server non-wine processes. If the answer is "yes", as is probably the case with an Adobe PDF printer driver, or with a winmodem's driver, root must install them.
If the answer is "no", then there is no breaking of the model. With the directory structure as defined today, each user can install it, claiming full admin rights over the loca directory structure. Of course, the new adobe's printer driver only serves his programs.
There is one problem with this model that has to do with windows programs that require admin in order to RUN. I know of a few of those. Some of them simply require DirectX, and these don't seem like a problem in Wine. Others require file access, and I was considering writing a program for Windows that will work around that by API remapping. I think it will be possible to make these programs work without breaking permissions. If so, it will certanly be easier to implement in Wine than in Windows.
Alexandre wasn't convinced it was useful enough to begin worrying about it:
IMO the real question is what do we need this for? Sure we can use Unix mechanisms to emulate running services as different users etc. but is that really what we need? What are these services doing that requires switching users? Is that how we want it to be done under Unix?
I think that if an application really requires extensive compatibility with the Windows security mechanism, then it may not be a good idea to run it under Unix at all, since it probably won't do what you want anyway. So what are the real world cases that require these kinds of things?
Martin did need it:
I have a real-world example for an application needing the service API and the logevent API. No user-account switching and "extensive compatibility with the Windows security mechanism" is required. It could very well be run in a special account, and doing that would IMO not raise substantial security issues.
All that's needed is a working service implementation in the sense that services can be registered which wine would start automatically when it's launched.
In the thread this week Greg Turner, RPC guru, gave some other reasons:
why do we need it? because it's in windows: q.e.d.
But in case that doesn't convince you: think it would be useless to run SQL Server or Backup Exec under wine? I don't. In fact I'd posit an opposite question: why should we bother implementing RPC if we don't plan to implement services? They go hand-in-glove IMHO.
|Valgrind for Wine||03/21/2003||Archive|
Ironically, I can't remember if I've ever posted anything using Valgrind to check Wine's memory management. It's definitely been discussed in the past. Adam Gundy reported success with getting Valgrind to check for memory problems:
hi... after much hard work and midnight oil, I have made valgrind (the memory access checking tool) work with WINE.
You can run multi-threaded Windows programs under WINE (under valgrind), and have stack traces printed out for all the memory errors both in WINE and in the Windows program (and yes there are a LOT in WINE itself).
the purpose of this email is just an initial heads up, and a question - in order to print stack traces from (debug) compiled windows binaries, I have borrowed some of the PDB and PE reading code from WINE and added it to valgrind. AFAIK there shouldn't be a (license) problem with this, since WINE is LGPL and valgrind is GPL, but I just wanted to check before putting my neck on the chopping block.
assuming no one has any problems with licensing, then my next job (hopefully early next week) will be to submit the valgrind patches to the valgrind development mailing list for consideration. after the valgrind people have had a few days to mull over the patches, I will submit the patches needed to WINE to make it work (limited architecture, plus some fixes for the more annoying bugs found by valgrind).
please DON'T fill my inbox with requests for these patches yet - hopefully they will be available shortly.
|Error Requiring 32/16 Bit DLL Combinations||03/24/2003||Archive|
I can see this as something others might have run into (I think I have before), so I'll post this short thread. Mike Hearn wanted to know why he was having trouble loading a DLL:
Does anybody know what could cause this error?
I checked, I don't haev comctrl.dll anywhere. I'm trying to get IE6 to work on an "out-of-the-box" Wine install, ie trying to move to a completely WineHQ setup rather than the winehq/crossover setup I was using before.
I was under the impression that thunking was only used for 32/16 bridging, and IE6 is a 32bit app, so I don't really understand why it's trying to load this library using LoadLibrary16... does anybody have some tips?
Dmitry Timoshkov diagnosed the problem, You are using comctl32.dll from Win9x which *requires* 16-bit counterpart commctrl.dll. Edit [DllOverrides] in wine.conf and make comctl32.dll=b, or copy commctrl.dll from a win9x distribution.
That worked for Mike, though he ran into other unrelated problems.
|QEMU x86 Emulator||03/23/2003||Archive|
Fabrice Bellard announced an x86 emulator, The first release of the QEMU x86 emulator is available at http://bellard.org/qemu/ . QEMU achieves a fast user space Linux x86 emulation on x86 and PowerPC Linux hosts by using dynamic translation. Its main goal is to be able to run the Wine project on non-x86 architectures.
The Reference Doc provides a pretty good background on how it works. It doesn't appear to be at the level of supporting Wine, but the basic framework is in place.
Ulrich Weigand was excited, Using gcc to generate code snippets is a *great* idea! This makes it really easy to port; I've already got it running on s390
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License, version 2.0.