> 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. does rm have such an option ? rm doesn't, so I don't see any reason for this code bloat if you want to be paranoid (or you distro want to be), do it in wine script (or in the .winewrapper extension)
> 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). that could bring some issues while trying to run a native executable from a mounted FAT driver (without the proper umask option for mount) (this could be circumvented by a drive configuration option in wine, but that would be a bit tricky to set for the average user) > 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. IMHO (regarding Klez), the main issue is the mail client not wine. It should protect/warn the user about this, not forward the blame on others > 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. I think this a more interesting alternative. People did start working on that (especially for SMB shares mounting) A+
