On Sun, 27 Oct 2002, 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 don't think this is necessary.
Either the user is already logged in as root, as in 'I typed root when XDM asked me my login' (or the system logged me in as root like in Lindows), and then he has more important things to worry about.
Or he logged in as a regular user and su-ed as root and is now running a Wine application. If he took the pain to su as root (and adjust $DISPLAY and permissions appropriately), then I would trust him to know what he is doing. Windows users don't su as root (they use the KDE/Mandrake/etc menu entries that automatically ask for the root password).
Anyway, this idea is so trivial to implement in the Wine wrapper (a shell script) that it is really not an issue, and can be left to packagers (to add or remove).
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).
As someone else pointed out this would break a lot of programs.
But there is an interesting aspect that I did not see mentioned before. The user reporting this says he was using KMail. I did some tests with KMail and whenever you open an attachement you get a warning that it may compromise your security. This may sound good but this happens for every single attachement: for text attachements, diff files, gifs, jpgs, everything. And this is a rule of security: if security measures get in the way they will be ignored. Here I'm sure KMail users just get the reflex of systematically clicking on Open don't even read the message after the first couple of times. To improve security KMail should issue warnings in a more discriminate manner (have a (user-configurable) list of known safe MIME types for instance).
[...]
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.
Again many people said Wine should not be configured to have access to your home directory or to /. But this would be a big usability problem and make Wine useless for all people using Wine in an office environment. In such an environment people need to open Word documents sent as attachement by collegues (/tmp/...), located on a file server (/mnt/server/....), or documents they work on ($HOME/...). Remove the drives that let them access these documents and Wine becomes so cumbersome to use that it is unusable.
In fact, arguing for the removal of these drives is a bit similar to arguing that Emacs should be run in a chroot-ed environment to protect you from malicious Lisp programs. Of course it means that you would have to copy files back and forth to edit them and thus no one is advocating that.