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.

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:

http://sourceforge.net/project/showfiles.php?group_id=6241

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 :).

For now things are pretty clear:

• the "Home" on SF points to www.winehq.org
• we are going to store only downloadable files on SF:
  • official tarballs
  • 3rd party support files that we can distribute
  • as many binary packages as possible (currently, we have binary packages for Debian and SuSE, but the respective maintainers have not voiced their opinion on the matter).
• the other SF features (mailing lists, CVS, bug tracker, patch tracker, etc.) are not currently used. However, I will try to monitor the bug & patch tracker in case people start using them.

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.

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

export LD_ASSUME_KERNEL=2.2.5

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.

See also

• http://www.winehq.org/hypermail/wine-devel/2003/02/0252.html
• http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83254
• http://ftp.yars.free.net/pub/software/unix/platforms/linux/dist/redhat/updates/rawhide/?C=S&O=A

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.

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.

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?

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:

• Installing a service == create an init script
• Set service as "automatic" == put the script in the default runlevel
• Uninstall a service == remove from all runlevels & remove init script
• ... etc.

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.

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.

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?

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.

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.

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.

Does anybody know what could cause this error?

err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2

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?