Re: ntdll: add a warning about running wine as root (resend)
Alexandre Julliard <julliard(a)winehq.org> wrote:
Sent: Feb 9, 2009 7:53 AM To: James Mckenzie <jjmckenzie51(a)earthlink.net> Cc: Austin English <austinenglish(a)gmail.com>, wine-devel(a)winehq.org Subject: Re: ntdll: add a warning about running wine as root (resend)
James Mckenzie <jjmckenzie51(a)earthlink.net> writes:
New wine installation:
su (no dash so root's environment is not picked up) wine notepad install various programs and use them. exit
This shouldn't hurt anything. Please specify the exact platform and show us the exact commands you are using, or better file a bug with that info.
It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment. Fortunately, I run a Mac and running as root is disabled and it is a lengthy process to enable that user, which I did to attempt to get around a problem that running as root did not fix. I agree that user education is key, educating some folks is hard. James McKenzie
James Mckenzie <jjmckenzie51(a)earthlink.net> writes:
It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment.
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this. I'm all for being more friendly to newbies, and that's precisely why I want to solve the actual problem (if there is one), not just print a warning and then tell them "it's your fault for not heeding the warning". We all know that people ignore warnings, so it doesn't add any user-friendliness at all, just the opposite. -- Alexandre Julliard julliard(a)winehq.org
On Mon, Feb 9, 2009 at 9:19 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
James Mckenzie <jjmckenzie51(a)earthlink.net> writes:
It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment.
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
I'm all for being more friendly to newbies, and that's precisely why I want to solve the actual problem (if there is one), not just print a warning and then tell them "it's your fault for not heeding the warning". We all know that people ignore warnings, so it doesn't add any user-friendliness at all, just the opposite.
To list as well, sorry Alexandre: That wasn't the case I was trying to warn against. I was trying to warn against running wine as root in general, unless you know the consequences. I see people being reminded several times a week of this in the forums (granted, less since we disabled using sudo). If we don't mind new users running as root who don't know better, then we should delete that from the FAQ, and quit recommending against it. The fact is we don't recommend it, because it has the potential to cause harm, and the majority of the time, is not needed (especially for those asking on the forum). However, we DO NOT want users running as root, as we've made it damn hard to do so, but as the adage goes, "Fool proof systems do not take into account the ingenuity of fools." A simple warning, printed in the terminal (at least on the first run of a prefix), should increase the foolproof-ness of the system (of course, still not 100%). -- -Austin
Alexandre Julliard wrote:
James Mckenzie <jjmckenzie51(a)earthlink.net> writes:
It does not hurt anything but Wine's reputation. I don't know, but the phrase "I would rather be run over rather than run down" does apply here. In other words, we should be getting positive responses to user experiences, rather than dealing with newbies having to delete their .wine directories because they ran Wine as root without setting to the root environment.
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration. vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine' Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:ole:apartment_createwindowifneeded CreateWindow failed with error 1114 err:ole:apartment_createwindowifneeded CreateWindow failed with error 1114 Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:ole:apartment_createwindowifneeded CreateWindow failed with error 1114 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 Could not load Mozilla. HTML rendering will be disabled. err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error 0 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:ole:apartment_createwindowifneeded CreateWindow failed with error -536870654 err:wgl:process_attach X11DRV or GDI32 not loaded. Cannot create default context. wine: configuration in '/root/.wine' has been updated. Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:ole:apartment_createwindowifneeded CreateWindow failed with error 1114
2009/2/10 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
Alexandre Julliard wrote:
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration.
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: Since when did sudo ask for root's password? It (normally?) asks for the user's password.
wine: created the configuration directory '/root/.wine' Is WINEPREFIX being passed to wine via sudo? For that matter, is sudo overriding $HOME on your system? Or have you run "su -c winecfg" and just replaced it with "sudo" above?
Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Interesting. xauth problem. Again, I'd be surprised if this happened with sudo. Not so surprised if it happened with "su -".
Ben Klein wrote:
2009/2/10 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
Alexandre Julliard wrote:
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration.
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: Since when did sudo ask for root's password? It (normally?) asks for the user's password.
wine: created the configuration directory '/root/.wine' Is WINEPREFIX being passed to wine via sudo? For that matter, is sudo overriding $HOME on your system? Or have you run "su -c winecfg" and just replaced it with "sudo" above?
Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Interesting. xauth problem. Again, I'd be surprised if this happened with sudo. Not so surprised if it happened with "su -".
Quoting myself:
default Open SuSE configuration.
Here is all the not commented content of the /etc/sudoers: Defaults always_set_home Defaults env_reset # And a long list of LC_* allowed env vars: Defaults env_keep = "LANG LC_* ... LINGUAS XDG_SESSION_COOKIE" Defaults targetpw # ask for the password of the target user i.e. root ALL<--->ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! root<-->ALL=(ALL) ALL Explains everything you see from 'sudo wine winecfg'. Vitaliy.
On Tue, 10 Feb 2009, Ben Klein wrote: [...]
Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Interesting. xauth problem. Again, I'd be surprised if this happened with sudo. Not so surprised if it happened with "su -".
X access will very often be broken after a sudo or an su (e.g. Debian). In fact I believe it will only work on distributions which install special PAM packages. For all others you should use gksu, kdesu or sux. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
Alexandre Julliard wrote:
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration.
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine'
As you can see it's creating a new prefix under /root, so it's not messing up the user's prefix. That's perfectly fine. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
Alexandre Julliard wrote:
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration.
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine'
As you can see it's creating a new prefix under /root, so it's not messing up the user's prefix. That's perfectly fine.
That part worked you are correct. However X11 part didn't (missing $DISPLAY). And even if $DISPLAY would be defined in this case all programs will be installed into root's env not user's. No menu entries, no desktop links no visible installed programs - big problem for noob users "where did my stuff go"? Vitaliy.
On Tue, Feb 10, 2009 at 8:38 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
Alexandre Julliard wrote:
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
Alexandre Julliard wrote:
Again, please demonstrate the exact sequence that leads to an actual problem, not just vague hearsay of people reporting problems that may or may not have anything to do with this.
Will this work? BTW default Open SuSE configuration.
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine'
As you can see it's creating a new prefix under /root, so it's not messing up the user's prefix. That's perfectly fine.
That part worked you are correct.
However X11 part didn't (missing $DISPLAY). And even if $DISPLAY would be defined in this case all programs will be installed into root's env not user's. No menu entries, no desktop links no visible installed programs - big problem for noob users "where did my stuff go"?
Vitaliy.
That's not the (main) problem. The main problem is people installing stuff as root when they have no reason to do so. Alexandre, how would you feel about a one time warning, e.g., by setting a registry key, a la wineboot when run on a new/updated prefix. -- -Austin
Austin English <austinenglish(a)gmail.com> writes:
That's not the (main) problem. The main problem is people installing stuff as root when they have no reason to do so.
Alexandre, how would you feel about a one time warning, e.g., by setting a registry key, a la wineboot when run on a new/updated prefix.
No, a warning that will get drowned in a bunch of other fixmes is not useful. What we should really do is properly support installing as root, i.e. having stuff go into a global prefix and being available to all users. -- Alexandre Julliard julliard(a)winehq.org
On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Austin English <austinenglish(a)gmail.com> writes:
That's not the (main) problem. The main problem is people installing stuff as root when they have no reason to do so.
Alexandre, how would you feel about a one time warning, e.g., by setting a registry key, a la wineboot when run on a new/updated prefix.
No, a warning that will get drowned in a bunch of other fixmes is not useful.
We could make it a popup warning, again, only on first run.
What we should really do is properly support installing as root, i.e. having stuff go into a global prefix and being available to all users.
IMHO, that's a separate issue, but something that we should do. -- -Austin
Austin English <austinenglish(a)gmail.com> writes:
On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
No, a warning that will get drowned in a bunch of other fixmes is not useful.
We could make it a popup warning, again, only on first run.
No, warning message boxes are just as useless, users have been conditioned by MS to click through without reading. If you really want to prevent users from running as root you have to refuse to create the prefix and abort, and then make them jump through hoops to create it manually, by running wineboot explicitly or something like that. -- Alexandre Julliard julliard(a)winehq.org
2009/2/10 Francois Gouget <fgouget(a)free.fr>:
On Tue, 10 Feb 2009, Ben Klein wrote: [...]
Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Interesting. xauth problem. Again, I'd be surprised if this happened with sudo. Not so surprised if it happened with "su -".
X access will very often be broken after a sudo or an su (e.g. Debian). In fact I believe it will only work on distributions which install special PAM packages. For all others you should use gksu, kdesu or sux.
I'm on Debian and I don't have trouble with X access when using su. "su -" is another matter entirely. I don't know about X access with sudo (because I've strictly restricted my sudo to only run certain commands. I like my root user :) ), but I'd imagine it'd work because $HOME is not overridden, so the sudo'd program would be using the original user's ~/.xauth file. Also, $DISPLAY would be set correctly. 2009/2/11 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
Alexandre Julliard wrote:
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
vitaliy(a)dragon:~ $export WINEPREFIX=~/.wine-root vitaliy(a)dragon:~ $sudo wine winecfg root's password: wine: created the configuration directory '/root/.wine'
As you can see it's creating a new prefix under /root, so it's not messing up the user's prefix. That's perfectly fine.
That part worked you are correct.
However X11 part didn't (missing $DISPLAY). And even if $DISPLAY would be defined in this case all programs will be installed into root's env not user's. No menu entries, no desktop links no visible installed programs - big problem for noob users "where did my stuff go"?
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working! Creating the wineprefix in root's home directory is expected behaviour if $HOME is being overridden by preference in /etc/sudoers. Take it up with the OpenSUSE guys if you don't like it. 2009/2/11 Alexandre Julliard <julliard(a)winehq.org>:
Austin English <austinenglish(a)gmail.com> writes:
On Tue, Feb 10, 2009 at 10:44 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
No, a warning that will get drowned in a bunch of other fixmes is not useful.
Probably not, but I've seen a lot of newbies run "sudo winecfg" because winecfg is a config tool, so they assume that it needs to be run by root. In these cases, a message on console would likely be visible, but I wouldn't be surprised if 90% of them still ignore it. "Where's my pretty GUI? Why do I have to read all this boring text?", that sort of thing.
We could make it a popup warning, again, only on first run.
No, warning message boxes are just as useless, users have been conditioned by MS to click through without reading.
Not just useless, but very, very annoying :) Plenty of times, I've started an app, gone to do some typing in another app, then a popup appears as I'm typing which steals focus and I end up hitting "OK" on it without being able to read it. Also, if we do think about a message box, we have to think about how to deliver it. It's been talked about before, and it can't be a Wine dialog due to the amount of initialisation required before that point (in particular, creating the wineprefix with wineboot). What options does that leave us? Dialogs that depend on GTK, QT or KDE backends? Choosing the "wrong one" here could annoy a lot of people, and for proper integration it'd have to be chosen on a per-system basis, thus supporting each method. What about xmessage? Two words: it's ugly. It'd likely annoy new users who suddenly see this ugly, old-styled dialog box in the middle of their fancy new system, and people would probably ask why we can't use something that better integrates with <insert DE here>.
If you really want to prevent users from running as root you have to refuse to create the prefix and abort, and then make them jump through hoops to create it manually, by running wineboot explicitly or something like that.
This is kinda what I've been getting at with earlier posts. Should a warning be a show-stopper? If so, this is a messy and unfriendly way of doing things. Let's not be Windows Vista-style UAC here, let's remember we're working on a Unix (or at least Unix-like) platform.
How about this: If uid = 0, SUDO_USER is set to a valid username, HOME is owned by that user, and WINEPREFIX is not set, then refuse to start, printing a message explaining the situation. Perhaps the message can be something like You're running Wine for the first time as root, but your home directory belongs to a normal user. Continuing would break Wine for that user. You probably want to run Wine as a normal user. Wine does not need to be root to install or run programs. This will stop naive ubuntu users who think they need installers from running Wine as root. Someone who has a legitimate need for root can get around this by using a configuration that isn't broken. Vincent Povirk
2009/2/11 Vincent Povirk <madewokherd+8cd9(a)gmail.com>:
How about this:
If uid = 0, SUDO_USER is set to a valid username, HOME is owned by that user, and WINEPREFIX is not set, then refuse to start, printing a message explaining the situation.
To abstract what you're saying here, you're suggesting to extend the wineprefix ownership test to include $HOME when $WINEPREFIX is not set and $HOME/.wine does not exist? That doesn't sounds like a bad idea to me. But I'm not so sure about specifically testing on UID=0 or SUDO_USER.
Perhaps the message can be something like
You're running Wine for the first time as root, but your home directory belongs to a normal user. Continuing would break Wine for that user.
You probably want to run Wine as a normal user. Wine does not need to be root to install or run programs.
This will stop naive ubuntu users who think they need installers from running Wine as root. Someone who has a legitimate need for root can get around this by using a configuration that isn't broken.
Vincent Povirk
To abstract what you're saying here, you're suggesting to extend the wineprefix ownership test to include $HOME when $WINEPREFIX is not set and $HOME/.wine does not exist?
That doesn't sounds like a bad idea to me. But I'm not so sure about specifically testing on UID=0 or SUDO_USER. This specifically covers the one case that is broken for people who maybe can't be expected to know any better: running wine for the first time using sudo on ubuntu. I don't know why else $HOME would not be owned by you, but I've been assuming we want Wine to function in those cases (otherwise, we'd have added this test when we added the original ownership test, right?).
If a user's home directory will always be owned by the user in a working Unix-like configuration, there's no need to test uid or SUDO_USER.
Fully automated bisecting with "git bisect run" [LWN.net]: http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ Would this be useful to add to the instructions on the wine wiki. Make Yahoo!7 your homepage and win a trip to the Quiksilver Pro. Find out more
2009/2/11 nn <saturn_systems(a)yahoo.com>:
Fully automated bisecting with "git bisect run" [LWN.net]: http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/
Would this be useful to add to the instructions on the wine wiki.
If I understand this correctly, this is only useful when the regression is something that can be tested without human interaction. This makes it virtually useless for Wine, as most regressions involve loss of functionality some application. However, it could theoretically be useful for regressions that cause a complete crash of the application early on. Would it be any faster? Probably not. Fewer commands to type, since you wouldn't need to run "git bisect bad" or "git bisect good" every time you test the app.
On Wed, Feb 11, 2009 at 7:06 AM, Ben Klein <shacklein(a)gmail.com> wrote:
If I understand this correctly, this is only useful when the regression is something that can be tested without human interaction. This makes it virtually useless for Wine, as most regressions involve loss of functionality some application.
How hard would it be to create some record/replay feature in wine ? As ("If" ?) any user interaction has to go through wine code, there is potentially enough data to reproduce anything, if collected. Of course, just as Selenium and selenium scenario generators (like http://seleniumhq.org/projects/ide/ ), it's probably not enough to just record user action and replay it, there must be some filtering done to make the test more robust. Another use for such system would be (just like Selenium) automated testing. That could ease app maintainer life, I guess. Sure, this is non-trivial to write, probably quite intrusive (I have no knowledge of the code involved) and maybe non-trivial to use... -- Vincent Pelletier
"Ben" == Ben Klein <shacklein(a)gmail.com> writes:
Ben> 2009/2/11 nn <saturn_systems(a)yahoo.com>: >> Fully automated bisecting with "git bisect run" [LWN.net]: >> http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ >> >> Would this be useful to add to the instructions on the wine wiki. >> Ben> If I understand this correctly, this is only useful when the Ben> regression is something that can be tested without human Ben> interaction. This makes it virtually useless for Wine, as most Ben> regressions involve loss of functionality some application. Ben> However, it could theoretically be useful for regressions that Ben> cause a complete crash of the application early on. Would it be any Ben> faster? Probably not. Fewer commands to type, since you wouldn't Ben> need to run "git bisect bad" or "git bisect good" every time you Ben> test the app. It should work it there is a test in the test suite too -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
On Wed, Feb 11, 2009 at 10:42:14AM +0100, Uwe Bonnes wrote:
"Ben" == Ben Klein <shacklein(a)gmail.com> writes:
Ben> 2009/2/11 nn <saturn_systems(a)yahoo.com>: >> Fully automated bisecting with "git bisect run" [LWN.net]: >> http://lwn.net/SubscriberLink/317154/5dec0c8146e58b61/ >> >> Would this be useful to add to the instructions on the wine wiki. >> Ben> If I understand this correctly, this is only useful when the Ben> regression is something that can be tested without human Ben> interaction. This makes it virtually useless for Wine, as most Ben> regressions involve loss of functionality some application.
Ben> However, it could theoretically be useful for regressions that Ben> cause a complete crash of the application early on. Would it be any Ben> faster? Probably not. Fewer commands to type, since you wouldn't Ben> need to run "git bisect bad" or "git bisect good" every time you Ben> test the app.
It should work it there is a test in the test suite too
Comments to the article suggest that it gets significantly more complex if you have 'toxic' patches in the tree. i.e. a patch that breaks your test but is a different bug. You test needs to catch this and return a different code to tell git to skip that revision. -- Darragh "Nothing is foolproof to a sufficiently talented fool."
Vincent Povirk <madewokherd+8cd9(a)gmail.com> writes:
To abstract what you're saying here, you're suggesting to extend the wineprefix ownership test to include $HOME when $WINEPREFIX is not set and $HOME/.wine does not exist?
That doesn't sounds like a bad idea to me. But I'm not so sure about specifically testing on UID=0 or SUDO_USER. This specifically covers the one case that is broken for people who maybe can't be expected to know any better: running wine for the first time using sudo on ubuntu. I don't know why else $HOME would not be owned by you, but I've been assuming we want Wine to function in those cases (otherwise, we'd have added this test when we added the original ownership test, right?).
No we don't want Wine to function in those cases, and it is part of the ownership test already. -- Alexandre Julliard julliard(a)winehq.org
No we don't want Wine to function in those cases, and it is part of the ownership test already.
wine: '/home/sudotest' is not owned by you, refusing to create a configuration directory there So it is. Well then, there's no need for an additional warning as far as I'm concerned. When was this added?
On Wed, Feb 11, 2009 at 11:02 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote:
No we don't want Wine to function in those cases, and it is part of the ownership test already.
wine: '/home/sudotest' is not owned by you, refusing to create a configuration directory there
So it is. Well then, there's no need for an additional warning as far as I'm concerned.
The problem is people doing: $ wine setup.exe # program doesn't work/error about admin rights/etc. $ sudo wine setup.exe wine: '/home/user/.wine' is not owned by you, refusing to create a configuration directory there $ sudo su # wine setup.exe I filed bug 17337 (http://bugs.winehq.org/show_bug.cgi?id=17337) for this. If you'd like to take a try at it, please do, not sure when I'll have time to do so.
When was this added?
http://source.winehq.org/git/wine.git/?a=commitdiff;h=3e8532779f1f93619f3686... -- -Austin
$ wine setup.exe # program doesn't work/error about admin rights/etc. $ sudo wine setup.exe wine: '/home/user/.wine' is not owned by you, refusing to create a configuration directory there $ sudo su # wine setup.exe
Ok, if I understand you, one of the following things happens after that: * The program fails in the same way. I don't think that's really a problem. * The program succeeds because it really did need to be root. That's not really a problem either, unless we can provide what the program needs without being root. * The program succeeds because root's .wine directory is pristine. That's bad. The user should just be running a new WINEPREFIX instead of root. Simply putting up an obstacle without suggesting an alternative won't help anyone. So we should be looking for a way to encourage users to try a new WINEPREFIX before trying things as root?
On Wed, Feb 11, 2009 at 11:40 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote:
$ wine setup.exe # program doesn't work/error about admin rights/etc. $ sudo wine setup.exe wine: '/home/user/.wine' is not owned by you, refusing to create a configuration directory there $ sudo su # wine setup.exe
Ok, if I understand you, one of the following things happens after that: * The program succeeds because root's .wine directory is pristine. That's bad. The user should just be running a new WINEPREFIX instead of root.
Yes. That, or some users try root from the beginning.
Simply putting up an obstacle without suggesting an alternative won't help anyone.
The permissions check cut down on people using sudo quite a bit. Removing drive c from winecfg prevented a lot of people mapping it to windows drives. Users are creative. Watch the forums and you'll notice these things.
So we should be looking for a way to encourage users to try a new WINEPREFIX before trying things as root?
Of course. We already encourage not running as root, but that doesn't mean it sinks in. Enforcing it in the code actually does some good. -- -Austin
Ben Klein wrote:
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working! This is something called security....
2009/2/11 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
Ben Klein wrote:
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working! This is something called security....
This is something called "nothing we have to worry about or address". It's not *expected* to work this way on your default OpenSUSE configuration. Note that security always comes at the cost of convenience. 2009/2/11 Vincent Povirk <madewokherd+8cd9(a)gmail.com>:
To abstract what you're saying here, you're suggesting to extend the wineprefix ownership test to include $HOME when $WINEPREFIX is not set and $HOME/.wine does not exist?
That doesn't sounds like a bad idea to me. But I'm not so sure about specifically testing on UID=0 or SUDO_USER. This specifically covers the one case that is broken for people who maybe can't be expected to know any better: running wine for the first time using sudo on ubuntu. I don't know why else $HOME would not be owned by you, but I've been assuming we want Wine to function in those cases (otherwise, we'd have added this test when we added the original ownership test, right?).
If a user's home directory will always be owned by the user in a working Unix-like configuration, there's no need to test uid or SUDO_USER.
Um ... not sure what you mean here, but the problem comes when $HOME is not owned by $USER due to sudo. The default configuration of sudo on most distros is to use the calling user's $HOME. Vitaliy has demonstrated that this is not true for OpenSUSE, but as it has been discussed, OpenSUSE doesn't do anything unexpected as a result. (It's effectively the same as doing "su - -c wine" whatever.) My point is that enforcing the test only on UID is not a particularly neat way to do it, because you'd get the same permissions problems if "sudo -u otheruser" is used. Also, that the default wineprefix is in $HOME, which does not and should not involve a lookup in /etc/passwd for the home directory of the user indicated in $USER (or $SUDO_USER), since this has already been done when setting up the environment. So Wine really doesn't need to do special things with $SUDO_USER.
On Tue, 10 Feb 2009, Vitaliy Margolen wrote:
Ben Klein wrote:
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working! This is something called security....
No, the whole point of using sudo is that it removes the necessity of anyone other than root knowing the root password. If OpenSuSE's default config requires anyone that needs elevated privileges to know the root password, it is broken. Using a properly configured sudo, the non-root users are allowed to execute a (possibly limited) number of commands with root privileges, but authenticating using their OWN password. Steve Brown sbrown7(a)umbc.edu
On Wed, Feb 11, 2009 at 09:35:26AM -0500, Steve Brown wrote:
On Tue, 10 Feb 2009, Vitaliy Margolen wrote:
Ben Klein wrote:
This is not a problem with Wine, this is OpenSUSE breaking the environment when sudo is called. Remember, Wine is not the only X11 app out there. Others will need $DISPLAY working! This is something called security....
No, the whole point of using sudo is that it removes the necessity of anyone other than root knowing the root password. If OpenSuSE's default config requires anyone that needs elevated privileges to know the root password, it is broken. Using a properly configured sudo, the non-root users are allowed to execute a (possibly limited) number of commands with root privileges, but authenticating using their OWN password.
sudo has more features that are good ... like keeping authentication for some time or specific roles. Thats why openSUSE keeps it secure this way (by using the root password). You can of course change this for yourself. This has been discussed to dead for openSUSE already, but if you want to discuss this further, move it to opensuse-security(a)opensuse.org. Ciao, Marcus
participants (13)
-
Alexandre Julliard -
Austin English -
Ben Klein -
Darragh Bailey -
Francois Gouget -
James Mckenzie -
Marcus Meissner -
nn -
Steve Brown -
Uwe Bonnes -
Vincent Pelletier -
Vincent Povirk -
Vitaliy Margolen