It shouldn't be that easy

P. Christeas p_christ at hol.gr
Sun Oct 27 08:02:07 CST 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 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.





More information about the wine-devel mailing list