"David D. Hagood" wrote:
P. Christeas wrote:
Write a segment of code that will abort wine, if it is run as root (that is, just before wine starts anything). This piece of code should only be explicitly disabled in the 'configure' script. That way, only a
I slightly disagree - I think the thing to do would be to have wine not run if UID == 0, UNLESS the commandline parameter --i-know-i-am-root is set, AND THEN pop up a dialog box that requires confirmation before continuing.
I would ALSO suggest that wine check the execute bit on the application being run - the recent incident with Klez running under Wine would not have happened (I think) if wine would not run that which is not marked with the -X bit (unless, again, a command line parameter is supplied, and a warning dialog is confirmed).
Since I know of no mail client for Linux that would set the X bit on an attachment, this would help protect users from themselves, while allowing those that need to be able to take the risks to do so.
And as for making "/" available as a Wine drive - how about creating a tool that would allow you to add or remove drive mappings at run time? So that if I find that I really do need /usr/foo/bar/baz available to Wine, I can run a program that tells wineserver to add that as drive Q: for now.
It should not be that easy. We can all understand that the 'klez' case wouln't have happened if wine had properly been configured. Windoze users are used to press 'OK' to all dialogs and grant privileges to any program asking for them. There is no practical reason a regular user would want to run Wine as root. That's what the *nix security model is all about. Wine developers should make sure there is no such need. The same applies for files. There is no reason a wine user would want to read/write protected files. If we make config available (the way you described it), wrong settings are bound to be made. We are just securing wine from its users.