System-wide installation of Windows applications

[Fred]

Binary package hint: wine

When I install an software application it gets installed into home directory,
and is only available to me.

Example, if I install World of Warcraft, it is 15 gigabyte.
Then my brother wants to play World of Warcraft and he have to install it again separately for his account.
So does my sister. That would be a lot of disk space wasted and lots of time consuming to install it for every user.

If I have guests over at a party, I might want to login into the Guest account. But I still want them to be able to use Spotify to change the music.

[Yolande (yolande)]

I will test your fix and send you a feedback straight away.

I have an application affected by this.

[Yolande (yolande)]

(In reply to comment #1)
> I will test your fix and send you a feedback straight away.
>
> I have an application affected by this.
>

Just to enlighten some, the .NET is taking the config file from Linux (yes, I have seen it!!!) and I have seen through a regression test that the changed here patched affected me.

[Mail-science (mail-science)]

Yes, this is good idea!

Your solution looks cleaner and smarter than what is currently implemented in
WINE.

Personally I currently is forced to use a hack to remove this useless (in my
case) check. I have a good reason for that - reconfiguring dozens of WINE
prefixes for a lot of users isn't an option (and WINE even don't provide
standard way to (re)configure for multiuser setup). Your patch fixes this
problem and creating multiuser setup with WINE (and your patch applied) is as
simple as creating multiuser setup with any other Linux application.

You need to send your patch to wine-patches mailing list. It is recommended to
subscribe to the mailing list before sending (you can do this here:
http://www.winehq.org/mailman/listinfo/wine-patches ). Thanks.

[Yolande (yolande)]

From my side *Thank you*.

This seems to clear bug 10584 (tested on SDLX which was affected and untouched by
my previous tests --> ending with "setup exception" and not "setup error"
(setup error was the error for the regression test).

[Alexandre Julliard (julliard)]

(In reply to comment #0)
>
> Unless I'm overlooking a better way to do this, it would make more sense to
> check proper permissions than to check ownership. I'm attaching a patch that
> does that.

No, the whole point of the patch is precisely to prevent separate wineserver instances from trying to write to the same registry files, since that doesn't work.

[Vitaliy-bugzilla (vitaliy-bugzilla)]

This is by design, as Alexandre said. Wine should not start when run as a different user with some one else's configuration. There are lots of "smart" users doing "sudo wine <blah>". This is what this check protects against. If you do not like it - have each user copy Wine config.

[Yolande (yolande)]

Dear Vitality,

I know you don't like issues about the .NET. However if the installshield is scanning the whole disk instead of just the wine prefix and installs some installation temporary files in the linux temp file which by definition belongs to root.
Now I have at least 20 files as per the attachment (some different kind of), they are all stored in the temp directory which is owned by root. The rights are owned by me, in an directory owned by root but I can't access them because the .NET did change the rights of them.

How do I solve this mess using sudo? Is there not a way of keeping Wine inside its boundaries then if it's not allowed to go into directories owned by root?

[Yolande (yolande)]

Dear Vitality,

Now I have a question for you: If I look into the wine directory, there is c: and z:. Unfortunately I have many temp files ending in z:\temp (java classes or OLE files that I can't access even if I am the owner because the .NET reverted the rights). Now the z: does belong to root and there is thus no way that wine can access to the z: because c: is yolande and z: is root. How do you solve that then? Do you have a sudo for z: in the middle of an installation procedure (please note that z:\temp does also belong to root).

[Bernhard Rosenkraenzer (berolinux)]

The intent of the original patch is to allow a setup where several users, let's call them "mom" and "dad", can share their Windoze applications without using the same account. Assuming the users are non-technical, it is safe to assume that they won't know how to copy registries around every time they install a new application, and it's also safe to assume that they won't be using the computer at the same time (at least not with different accounts) -- this is a pretty common situation and IMO should be addressed in some way.

Of course it also opens the possibility to mess up by running wine something.exe and sudo wine something.exe simultaneously - maybe the best way to stop that is creating a lock file in the config directory that is writable by the user only, and if it's there and owned by another user, abort with an error message saying "dad is currently using wine, please wait until he is done or create a separate wineprefix using wineprefixcreate"?

[Yolande (yolande)]

Created an attachment (id=10156)
One of the things that I get from Wine into z:

Not being able to save such a file in the temp directory (owned by root) is causing the installation to abort with a setup error.

[Alexandre Julliard (julliard)]

Temp files should go under c: somewhere, if they go in z:\temp there's something wrong with your setup. In any case it's unrelated to this bug.

Still, the actual problem that my hack was fixing could be fixed a better way, so this bug should remain open.

[Marco-harddisk (marco-harddisk)]

@Vitaliy: For those "smart" users running wine through sudo, I have written a patch which was rejected - maybe it gets its revival here.

Or there should be some kind of configuration option to disable the owner-check, I think of winecfg here.

[Austin English (austinenglish)]

Do we want to support multiple users sharing the same prefix? I haven't seen too much about this lately, though I know in the past you could share a drive c, dosdevices and system.reg, but that the user.reg and userdef.reg had to be unique to the user. Is that still the case? If so, we could only check that user/userdef.reg are user owned/writable, but on the others, check that we have the correct permission, not ownership.

[Vitaliy-bugzilla (vitaliy-bugzilla)]

(In reply to comment #8)
> Dear Vitality,
>
> Now I have a question for you: If I look into the wine directory, there is c:
> and z:. Unfortunately I have many temp files ending in z:\temp (java classes
> or OLE files that I can't access even if I am the owner because the .NET
> reverted the rights). Now the z: does belong to root and there is thus no way
> that wine can access to the z: because c: is yolande and z: is root. How do you
> solve that then? Do you have a sudo for z: in the middle of an installation
> procedure (please note that z:\temp does also belong to root).
>

rm -rf ~/.wine
Clearly it's screwed up. Don't f** with something you have no concepts about. Still don't see a bug here. So far you've been talking about how badly you managed to break your setup.

(In reply to comment #12)

> @Vitaliy: For those "smart" users running wine through sudo, I have written a
> patch which was rejected - maybe it gets its revival here.
Ask Julliard, not me.

(In reply to comment #11)
> Temp files should go under c: somewhere, if they go in z:\temp there's
> something wrong with your setup. In any case it's unrelated to this bug.
>
> Still, the actual problem that my hack was fixing could be fixed a better way,
> so this bug should remain open.
>

Hack what hack? I thought those not allowed in.

(In reply to comment #13)
> Do we want to support multiple users sharing the same prefix? I haven't seen
> too much about this lately, though I know in the past you could share a drive
> c, dosdevices and system.reg, but that the user.reg and userdef.reg had to be
> unique to the user. Is that still the case? If so, we could only check that
> user/userdef.reg are user owned/writable, but on the others, check that we have
> the correct permission, not ownership.
>

No, this can not be supported. Wineserver does not sync with registry on the disk. It only writes there on exit or periodically (if configured). So you'll loose someone's changes.

[Yolande (yolande)]

I have deleted the wine prefix at least 30 times this week!!!

Don't tell me it is enough just to delete the wine prefix! I have even reinstalled the whole Linux and the temp are going there again and again.
At the most it is because the net is taking the .config file of linux and reading amongst others that the temp is here!

If you know somebody from Austria (around Vienna) he/she is free to come and delete my prefix 100 times, it will be installed 100 times again there (provided you empty the cache every time).

[Mail-science (mail-science)]

Yolande Haneder, please open a separate bug report if you *really* think that a problem you found is a bug in WINE. But it is unrelated to this bug report. This bug report is about a problem with multiuser setup, and only one problem per bug is allowed.

---

I think that should be a registry switch (somewhere in Software\Wine registry branch) and a command-line option to disable this check. This will solve all problems. For example:

wine --disable-owner-check notepad

Or (short switch):

wine -d notepad

Having ability to disable unnecessary checks is the standard in the Linux World. Especially this is true for checks that are exist only as protection from newbie users (or users who don't understand what he/she is doing). Expert users should be able to do what they want to do.

[Yolande (yolande)]

Dear L.

I do understand your point. I just came to this bug because as I wrote my first message, the second was not there and I was happy that someone else came to the conclusion that this check was creating problem.

I will not open a bug because I already have one about the setup error which ended with a regression test and my trying to understand what it had to do with me. Since then I reverted the commmit once, got my tmp files and the problem is bypassed.

I just would like that Vitality one day understand that I am not doing anything outside the rules when talking about a .NET problem because he can't reproduce it. I can reproduce it and I think it might work on red hat, solaris and mac as well as from sled (for the others I am not sure). I can get a foreign notebook with sled and install it there too. There is nothing about specific settings or that I corrupted anything.

I won't add anything anymore - promised!

[Alexandre Julliard (julliard)]

(In reply to comment #16)
> I think that should be a registry switch (somewhere in Software\Wine registry
> branch) and a command-line option to disable this check. This will solve all
> problems. For example:
>
> wine --disable-owner-check notepad
>
> Or (short switch):
>
> wine -d notepad
>
> Having ability to disable unnecessary checks is the standard in the Linux
> World. Especially this is true for checks that are exist only as protection
> from newbie users (or users who don't understand what he/she is doing). Expert
> users should be able to do what they want to do.

The check can be disabled by creating a temporary wineprefix dir that contains symlinks to the real files. For an expert user that's surely not harder than specifying a command line option.

[Mail-science (mail-science)]

> The check can be disabled by creating a temporary wineprefix dir that
> contains symlinks to the real files. For an expert user that's surely not
> harder than specifying a command line option.

I know that and I even recommended doing this on wine-users mailing list some time ago as possible solution for this problem.

However what if I'm creating new WINE prefixes frequently? For example, new prefix for new set of Windows programs (sometimes there is good technical reasons for doing this, especially in multiuser setup). I need then to write a script to bypass this check and launch it for each new WINE prefix. Yes, I can do that (in fact, I'm professional Linux programmer - in other words, this is my occupation). But fixing the problem in WINE source is not only faster but more convenient (because there is no need to write a wrapper script for wineprefixcreate; and I'm recompiling WINE git tree after each update anyway).

I see no harm in adding at least command-line switch (this is very easy to implement because interaction with registry isn't required). In fact, this is traditional practice. User who didn't read the documentation will not be able to bypass the check. And user who did read the documentation (or was instructed by an expert) will be able to do what he/she want to do - without spending time for writing wrapper script or modifying the source code.

By the way, not all users who need multiuser setup are programmers. But most users can easily add an alias or command-line switch. This is especially important when helping a user to create working multiuser setup with WINE. I can easily explain how to add command-line switch (and what problems might happen because of its use) or create an alias but explaining how to create symlinks for each user is much more harder (at least that's my real-life experience). This is why I care about this problem.

My final question is: can I expect a patch adding such command-line option to be accepted?

[Alexandre Julliard (julliard)]

(In reply to comment #19)

> My final question is: can I expect a patch adding such command-line option to
> be accepted?

No. I agree with you that it would be nice to make it easier to create robust multi-user setups, but the way to do that is not to provide an option to bypass the security check. The check is here because it's currently not possible to make multiple users share a wineprefix reliably; playing with permissions is certainly not enough, sooner or later you'll get a corrupted registry.

What needs to be done is to fix the code so that the multiple servers case is detected and handled correctly. Once this is done the check can be removed.

[Mail-science (mail-science)]

Thank you for explanation.

> What needs to be done is to fix the code so that the multiple servers case is
> detected and handled correctly. Once this is done the check can be removed.

OK, I agree, this would be better solution.

Then this bug is about lack of proper support for multiple wineservers running simultaneously. Can someone change the bug summary to something more appropriate? For example, "Running multiple wineservers simultaneously can corrupt registry".

[Mail-science (mail-science)]

Perhaps this bug should be nominated for 1.2?

[Tefnet Developers (developers-tefnet)]

*** This bug has been confirmed by popular vote. ***

[Austin English (austinenglish)]

Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!

[Dan Kegel (dank)]

Supporting multiple wineservers on same prefix doesn't
seem like a 1.2 kind of bug to me.

[Fred (eldmannen+launchpad)]

Binary package hint: wine

When I install an software application it gets installed into home directory,
and is only available to me.

Example, if I install World of Warcraft, it is 15 gigabyte.
Then my brother wants to play World of Warcraft and he have to install it again separately for his account.
So does my sister. That would be a lot of disk space wasted and lots of time consuming to install it for every user.

If I have guests over at a party, I might want to login into the Guest account. But I still want them to be able to use Spotify to change the music.

[Austin English (austinenglish)]

*** Bug 22388 has been marked as a duplicate of this bug. ***

[Dimesio (dimesio)]

*** Bug 23053 has been marked as a duplicate of this bug. ***

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for reporting this bug.

Does this still happen in newest WINE?

[Fred (eldmannen+launchpad)]

Yes.
Even with Ubuntu 10.04 and Wine 1.3.2 there is no way to install applications system-wide so they get available for all users.

[Fred (eldmannen+launchpad)]

They could install in /opt/wine/ maybe.

[Peter Quiring (pquiring)]

One way this could get fixed is if wineserver was overhauled a little to delay loading the HKCU registry key until each client connects. The HKCU key would be attached to each connection instead of being global. As the wine client connects it would first announce the username/sid and then wineserver could load the user.reg file from the users .wine folder.
This means that wineserver would have to run as root to load other users files like a system service.
wineserver -s, --service multi-user service

[Y-paulc (y-paulc)]

(In reply to comment #28)
> One way this could get fixed is if wineserver was overhauled a little to delay
> loading the HKCU registry key until each client connects. The HKCU key would
> be attached to each connection instead of being global. As the wine client
> connects it would first announce the username/sid and then wineserver could
> load the user.reg file from the users .wine folder.
> This means that wineserver would have to run as root to load other users files
> like a system service.
> wineserver -s, --service multi-user service

Running wineserver as root is a very complex problem by itself. It would mean that wineserver would need to reimplement many of the access rights normally provided by the operating system. The security implications are mindblowing.

Maybe we should focus on a slightly different problem that seems easier to implement since it doesn't seem that simultaneous access from different users is needed.

We could have a setuid wrapper that performs the equivalent of chown -R user once it locked the wineprefix and then switches back to the original user. This way the access rights will be correct.

A helpful touch would be to move user.reg inside c:\users\%USERNAME% so each user will have its own HKCU.

[oiaohm (oiaohm)]

Lets see if we can avoid this hell.

Remember current wine default is admin level user.

Can we enable limited usermode. This means that system hive become read only. Of course user hives remain read write.

Directory layouts as I dream them.
/opt/shared-application/
system.reg
drive_c/
dosdevices/
userdef.reg
user.reg
limited.ver

~/.wine
limited->/opt/shared-application/
dosdevices/
userdef.reg
user.reg
profile/
limited.ver

So drive_c and system.reg are read only to everyone accept admin. limited.ver contains a number that is increased when shared-application is edited.

Key thing here is we don't need a global wineserver to make this work. We don't need to be changing permissions all the time.

We just need a per user wineserver that can cope with the fact that system.reg is read only and drive_c is read only. Due to version tag alterations to read only drive_c could be recorded temp in user profiles and cleared when version increases.

Limited user mode would allow some applications to be run shared. Not all applications expect to write into there application directories and the like.

[Austin English (austinenglish)]

*** Bug 31026 has been marked as a duplicate of this bug. ***

[Austin English (austinenglish)]

*** Bug 45164 has been marked as a duplicate of this bug. ***

[Scott Ritchie (scottritchie)]

Closing ancient wine1.2 bugs