http://bugs.winehq.org/show_bug.cgi?id=10324
Summary: Running Wine as root should generate warning Product: Wine Version: 0.9.48. Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: austinenglish@gmail.com
Since running Wine as root can cause so many problems/damage, there should be some way to either warn/prevent users from doing so. Looking at gedit (http://www.gnome.org/projects/gedit/) while editing some files in Ubuntu got me thinking that a small popup warning that running Wine as root can cause severe damage/etc and/or refusing to run as root would be a good idea.
Shouldn't be too terribly hard to implement, and could hopefully prevent some users from damaging their systems/losing data.
http://bugs.winehq.org/show_bug.cgi?id=10324
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.0.0
--- Comment #1 from Austin English austinenglish@gmail.com 2007-11-05 21:26:17 --- Setting for 1.0.0 target.
http://bugs.winehq.org/show_bug.cgi?id=10324
L. Rahyen mail@science.su changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@science.su
--- Comment #2 from L. Rahyen mail@science.su 2007-11-05 22:01:27 --- Refusing to run as root isn't an option because sometimes this is necessary. Warning is enough. Of course warning should be understandable by simple user. For example: "WARNING: You are running WINE as root! This may harm your system!".
http://bugs.winehq.org/show_bug.cgi?id=10324
Eric Mullins emwine@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |emwine@earthlink.net
--- Comment #3 from Eric Mullins emwine@earthlink.net 2007-11-06 13:16:06 --- It's probably wise to provide a way to silence this, either through existing or a new env variable. It's a good idea though.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #4 from Austin English austinenglish@gmail.com 2007-11-06 13:22:52 --- In reply to comment 2: I thought about that after submitting the bug, since some programs require access to privileged ports, etc. But a simple pop-up should hopefully prevent those who don't know better from using it as root, but those who know what they're doing/need it will continue on as usual.
In reply to comment 3: Could put something in winecfg as well, or a registry key to override.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #5 from L. Rahyen mail@science.su 2007-11-06 14:21:01 --- I don't think that popup is the best option because most users who run as root unintentionally run WINE from console. So I think that warning in the console is enough. If the user run WINE using GUI (for example from Konqueror or Nautilus by clicking on Windows executables) it will most likely run it as simple user. At least this is what we can expect from most distros. However there is some Linux distributions like SLAX (SLAX: Kill Bill edition have WINE installed by default) which run *everything* as root intentionally. We may like or dislike such distributions (personally I dislike them) but WINE should support all real-world environments and shouldn't annoy users too much without cause.
And yes, ability to override this to hide the warning is a good idea. Environment variable is a good option. But having registry key for this purpose is good idea too. Maybe best way will be to support both environment variable and registry key? For example WINE can read dll overrides either from environment (high priority) or the registry (low priority). So it should be easy to make it use both registry key and environment variable to explicitly silence the warning.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #6 from Austin English austinenglish@gmail.com 2007-11-06 14:25:10 --- Would seem to me that on some programs that have a lot of output, the warning may get lost in the terminal and never seen, thus defeating the whole point of the warning. Sort of how many users never see warnings to fix their sound settings/etc, then go on to report a bug that is soon after closed invalid. Just my $.02.
As for supporting environmental variables/registry setting, I don't see a reason we can't have both.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #7 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-06 21:05:51 --- Anything GUI is not an option, because if you really logged in as root (not sudo, but 'su -l root') then DISPLAY var will not be set. Thus "disabling" any GUI not just for Wine but any other program. This also means no shell wrapper will help here either.
So a big fat warning that they should not do such a stupid thing generated from the wine loader (before they had a chance to destroy their WINEPREFIX). This also eliminates registry. So the only choice left is an environment variable or a command line switch.
Might be even an outright refusal to run as root if that env var is not set / option not given.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2007-11-07 03:22:32 --- There's no reason to prevent people from running as root. If doing that destroys their WINEPREFIX that's a bug we need to fix.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #9 from Austin English austinenglish@gmail.com 2007-11-07 10:45:06 --- I was thinking more along the lines of locking up the system, wiping out important files (/etc, /var, /boot, etc). Not their wine prefix. It may also set some files in their home directory to be owned by root:root, which could cause confusion.
Having seen several people file bugs about lockups/other strange errors after having run wine as root/sudo was what made me think of this. While there are some instances that people need to run as root and know what they are doing, more often it's people who don't know what they're doing and think it will help for some reason.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #10 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-07 14:20:16 --- (In reply to comment #8) Well it does not destroy it, it makes some important files owned by root and 644 permission: $ls -la ~/.wine total 488 drwxr-xr-x 2 vitaliy vitaliy 168 2007-10-07 09:33 dosdevices drwxr-xr-x 4 vitaliy vitaliy 168 2007-09-19 23:12 drive_c -rw-r--r-- 1 root root 437211 2007-11-07 13:17 system.reg -rw-r--r-- 1 root root 2392 2007-11-07 13:17 userdef.reg -rw-r--r-- 1 root root 53649 2007-11-07 13:17 user.reg
That's what breaks. Unless you have some other suggestions about these files Wine really should quit before doing any permanent harm.
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2007-11-07 16:16:27 --- What it should do is use root's .wine not the user's one. It shouldn't be hard to fix.
http://bugs.winehq.org/show_bug.cgi?id=10324
Darragh Bailey felix@compsoc.nuigalway.ie changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felix@compsoc.nuigalway.ie
--- Comment #12 from Darragh Bailey felix@compsoc.nuigalway.ie 2007-11-26 19:57:04 ---
Shouldn't the only case where wine will accidentally cause root to attempt to take ownership of the files under ~/.wine, is where wine is started via sudo, which will not set the HOME environment variable unless explicitly told to do so?
http://bugs.winehq.org/show_bug.cgi?id=10324
Marco Schuster marco@harddisk.is-a-geek.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco@harddisk.is-a-geek.org
--- Comment #13 from Marco Schuster marco@harddisk.is-a-geek.org 2007-12-17 14:40:29 --- When running wine via sudo in .51, this fails now. Now only thing is left is a warning for root in general.
http://bugs.winehq.org/show_bug.cgi?id=10324
Daniel Teichman danielteichman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |danielteichman@gmail.com
--- Comment #14 from Daniel Teichman danielteichman@gmail.com 2008-02-17 23:46:53 --- I think there should be a warning to allow the user to cancel running wine as root. If the user accepts, they should be warned that a chmod to their .wine may be necessary.
http://bugs.winehq.org/show_bug.cgi?id=10324
Plamen Vassilev plamen.vassilev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |plamen.vassilev@gmail.com
--- Comment #15 from Plamen Vassilev plamen.vassilev@gmail.com 2008-03-20 03:27:42 --- I think that the best way is for wine to simply print an error/warning and refuse to run as root unless told so by a command line switch (like --allow-root-user or something). Warning could be easily lost when running application which produces a lot of console output, and not seen at all if wine is started by a desktop link. Using command line switch implies that the user is both warned, and (hopefully) knows what they're doing. Thus (I think) we got best from the both worlds, wine is not accidentally started by root, and allowing to start wine as root if absolutely necessary. I imagine it could look like:
root@host:~#wine notepad ERROR: You are strongly discoraged to run wine as root user. (Some explanation may follow.) If you absolutely need to run wine as root, please consult the man/documentation/FAQ/README or whatever. Exitting!
the key point here is not to specify the exact option switch because it's likely that most users will just copy/paste it on the command line and rerun wine as root. At least making them run though the documentation (hopefully) gives them additional education.
http://bugs.winehq.org/show_bug.cgi?id=10324
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #16 from Dan Kegel dank@kegel.com 2008-03-20 18:50:54 --- I implemented the error - http://www.winehq.org/pipermail/wine-patches/2008-March/051860.html - but Alexandre didn't like it; see http://www.winehq.org/pipermail/wine-devel/2008-March/063829.html
I'm going to try moving it so it only happens at wineprefixcreate time...
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #17 from Dan Kegel dank@kegel.com 2008-03-20 19:25:47 --- 2nd try at http://www.winehq.org/pipermail/wine-patches/2008-March/051872.html
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #18 from Austin English austinenglish@gmail.com 2008-03-21 14:24:57 --- With a few patches by Alexandre, this is mostly fixed. For example (these are all in wine 0.9.58):
$ rm -rf ~/.wine $ sudo ~/wine-git/wine notepad wine: '/home/austin' is not owned by you, refusing to create a configuration directory there
$ rm -rf ~/.wine $ wineprefixcreate $ sudo ~/wine-git/wine notepad wine: /home/austin/.wine is not owned by you
and if I login as root (not recommended, obviously, but power users may want to for some reason). # wineprefixcreate /root/.wine updated successfully. # rm -rf ~/.wine # wine notepad wine: creating configuration directory '/root/.wine'... wine: '/root/.wine' created successfully.
However, there's still one issue: $ rm -rf ~/.wine $ sudo ~/wine-git/tools/wineprefixcreate Could not load Mozilla. HTML rendering will be disabled. /home/austin/.wine updated successfully. $ sudo ~/wine-git/wine notepad
Still works fine. Not sure if that was by intention or not (I have the feeling it wasn't).
http://bugs.winehq.org/show_bug.cgi?id=10324
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2008-03-21 17:34:34 --- (In reply to comment #18)
However, there's still one issue: $ rm -rf ~/.wine $ sudo ~/wine-git/tools/wineprefixcreate Could not load Mozilla. HTML rendering will be disabled. /home/austin/.wine updated successfully. $ sudo ~/wine-git/wine notepad
Still works fine. Not sure if that was by intention or not (I have the feeling it wasn't).
Yes, it is. There needs to be some way to work around the check if there's a good reason for it, and explicitly doing sudo wineprefixcreate is the way to do that. There's no reason for a user to run wineprefixcreate by itself, so it's not a problem to allow it.
http://bugs.winehq.org/show_bug.cgi?id=10324
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #20 from Austin English austinenglish@gmail.com 2008-03-21 18:34:11 --- (In reply to comment #19)
Yes, it is. There needs to be some way to work around the check if there's a good reason for it, and explicitly doing sudo wineprefixcreate is the way to do that. There's no reason for a user to run wineprefixcreate by itself, so it's not a problem to allow it.
After I posted my comment I was starting to think that would be the reason. I consider this bug fixed then. Should prevent most users from screwing up stuff, but gives power users the ability when needed. Hooray comprimise!
http://bugs.winehq.org/show_bug.cgi?id=10324
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #21 from Austin English austinenglish@gmail.com 2008-03-21 18:34:32 --- And closing since it's in wine 0.9.58.
http://bugs.winehq.org/show_bug.cgi?id=10324
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other
--- Comment #22 from Austin English austinenglish@gmail.com 2012-02-23 15:11:11 CST --- Removing deprecated 'All' Platform/OS.
-
wine-bugs＠winehq.org