[Bug 10324] New: Running Wine as root should generate warning
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(a)winehq.org ReportedBy: austinenglish(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.0.0 --- Comment #1 from Austin English <austinenglish(a)gmail.com> 2007-11-05 21:26:17 --- Setting for 1.0.0 target. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 L. Rahyen <mail(a)science.su> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail(a)science.su --- Comment #2 from L. Rahyen <mail(a)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!". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Eric Mullins <emwine(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emwine(a)earthlink.net --- Comment #3 from Eric Mullins <emwine(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #4 from Austin English <austinenglish(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #5 from L. Rahyen <mail(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #6 from Austin English <austinenglish(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #7 from Vitaliy Margolen <vitaliy(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #8 from Alexandre Julliard <julliard(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #9 from Austin English <austinenglish(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #10 from Vitaliy Margolen <vitaliy(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #11 from Alexandre Julliard <julliard(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Darragh Bailey <felix(a)compsoc.nuigalway.ie> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix(a)compsoc.nuigalway.ie --- Comment #12 from Darragh Bailey <felix(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Marco Schuster <marco(a)harddisk.is-a-geek.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marco(a)harddisk.is-a-geek.org --- Comment #13 from Marco Schuster <marco(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Daniel Teichman <danielteichman(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |danielteichman(a)gmail.com --- Comment #14 from Daniel Teichman <danielteichman(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Plamen Vassilev <plamen.vassilev(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |plamen.vassilev(a)gmail.com --- Comment #15 from Plamen Vassilev <plamen.vassilev(a)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(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #16 from Dan Kegel <dank(a)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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #17 from Dan Kegel <dank(a)kegel.com> 2008-03-20 19:25:47 --- 2nd try at http://www.winehq.org/pipermail/wine-patches/2008-March/051872.html -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #18 from Austin English <austinenglish(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 --- Comment #19 from Alexandre Julliard <julliard(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #20 from Austin English <austinenglish(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Austin English <austinenglish(a)gmail.com> 2008-03-21 18:34:32 --- And closing since it's in wine 0.9.58. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10324 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other OS/Version|All |other --- Comment #22 from Austin English <austinenglish(a)gmail.com> 2012-02-23 15:11:11 CST --- Removing deprecated 'All' Platform/OS. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org