Launchpad has imported 28 comments from the remote bug at http://bugs.winehq.org/show_bug.cgi?id=11112.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2008-01-10T03:12:42+00:00 Bero-arklinux wrote: Created an attachment (id=10147) Proposed fix Recent wine versions abort on startup if the config directory isn't owned by the user running wine. This breaks setups where several users share a common wine prefix (e.g. to make applications that make heavy use of the registry available to several users without installing them several times) and they have the right access to the configs through group permissions. 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/0 ------------------------------------------------------------------------ On 2008-01-10T03:24:29+00:00 Yolande wrote: I will test your fix and send you a feedback straight away. I have an application affected by this. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/1 ------------------------------------------------------------------------ On 2008-01-10T03:33:25+00:00 Yolande wrote: (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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/2 ------------------------------------------------------------------------ On 2008-01-10T03:54:08+00:00 Mail-science wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/3 ------------------------------------------------------------------------ On 2008-01-10T03:57:35+00:00 Yolande wrote: >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). Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/4 ------------------------------------------------------------------------ On 2008-01-10T05:01:59+00:00 Alexandre Julliard wrote: (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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/5 ------------------------------------------------------------------------ On 2008-01-10T10:00:31+00:00 Vitaliy-bugzilla wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/6 ------------------------------------------------------------------------ On 2008-01-10T11:20:55+00:00 Yolande wrote: 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? Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/7 ------------------------------------------------------------------------ On 2008-01-10T11:31:49+00:00 Yolande wrote: 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). Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/8 ------------------------------------------------------------------------ On 2008-01-10T11:35:57+00:00 Bero-arklinux wrote: 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"? Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/9 ------------------------------------------------------------------------ On 2008-01-10T11:53:11+00:00 Yolande wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/10 ------------------------------------------------------------------------ On 2008-01-10T12:09:22+00:00 Alexandre Julliard wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/11 ------------------------------------------------------------------------ On 2008-01-10T12:14:35+00:00 Marco-harddisk wrote: @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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/12 ------------------------------------------------------------------------ On 2008-01-10T12:24:58+00:00 austin_is wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/13 ------------------------------------------------------------------------ On 2008-01-10T13:27:25+00:00 Vitaliy-bugzilla wrote: (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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/14 ------------------------------------------------------------------------ On 2008-01-10T23:32:53+00:00 Yolande wrote: 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). Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/15 ------------------------------------------------------------------------ On 2008-01-11T01:08:19+00:00 Mail-science wrote: 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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/16 ------------------------------------------------------------------------ On 2008-01-11T01:25:40+00:00 Yolande wrote: 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! Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/17 ------------------------------------------------------------------------ On 2008-01-11T04:40:50+00:00 Alexandre Julliard wrote: (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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/18 ------------------------------------------------------------------------ On 2008-01-11T06:17:01+00:00 Mail-science wrote: > 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? Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/19 ------------------------------------------------------------------------ On 2008-01-11T08:02:37+00:00 Alexandre Julliard wrote: (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. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/20 ------------------------------------------------------------------------ On 2008-01-11T09:39:54+00:00 Mail-science wrote: 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". Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/21 ------------------------------------------------------------------------ On 2008-04-12T00:27:56+00:00 Mail-science wrote: Perhaps this bug should be nominated for 1.2? Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/22 ------------------------------------------------------------------------ On 2008-04-13T03:56:00+00:00 Tefnet Developers wrote: *** This bug has been confirmed by popular vote. *** Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/23 ------------------------------------------------------------------------ On 2009-01-18T03:47:33+00:00 austin_is wrote: 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! Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/24 ------------------------------------------------------------------------ On 2009-11-01T07:31:26+00:00 Dan Kegel wrote: Supporting multiple wineservers on same prefix doesn't seem like a 1.2 kind of bug to me. Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/25 ------------------------------------------------------------------------ On 2010-04-17T13:05:00+00:00 austin_is wrote: *** Bug 22388 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/27 ------------------------------------------------------------------------ On 2010-06-06T09:15:21+00:00 Dimesio wrote: *** Bug 23053 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/wine/+bug/565342/comments/28 ** Changed in: wine Importance: Unknown => Wishlist -- System-wide installation of Windows applications https://bugs.launchpad.net/bugs/565342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
