On Thursday 24 October 2002 12:30 am, Dimitrie O. Paun wrote:
On October 22, 2002 12:24 pm, Martin Wilck wrote:
The fact that wine cannot change user personalities and is lacking most of the NT security concepts makes services pretty useless.
I was thinking, can't we somehow use stuff like sudo(8) to accomplish that? I personally haven't used sudo(8), but if we do support services, we have to integrate nicely with the Unix world, IMO.
A system administrator already could do this. Anyhow there's really no need to bring sudo into the picture. If a sysadmin is crazy enough to want to run a wine "service" as root, they could just invoke their executable from an init script; that's more "service" like anyhow.
OTOH, I guess sudo could be used like this: if we are going to go the route of "being uncompromisingly unixey" then the services API should just manipulate init scripts. So, for example:
Installing a service == create an init script Set service as "automatic" == put the script in the default runlevel Uninstall a service == remove from all runlevels & remove init script ... etc.
Now, we create "wineservices.exe", create sudo permissions on this for the appropriate users, and implment it very, very carefully.
Needless to say, this is a very sketchy proposition. It is "correct," from a certain perspective; it's also very, very likely that people will use it to create huge gaping security holes in their system, like basically allowing themselves to run arbitrary scripts as root with very little effort, and then, inevitably, wine will get a bad rap as a result.
I'm starting to lean towards the opinion that if these security and identity aspects start to be implemented, then wine should just have its own user database, kind of like samba. So, for example, we create a database that maps unix users onto wine users, with flexible percieved windows permissions within the wine sandbox, or, in server environments, wine maps unix accounts onto domain accounts from the server.
This way, a user could "be administrator" within wine, but not be root on their unix box. If we just thunk wine security down to unix security, we are ignoring a very important difference between Windows and UNIX: the vast majority of unix users don't run as root; whereas the majority of Windows users /do/ run as Administrator or some equivalent.
An example: wine users need to run installers. Installers, as often as not, need Administrator permissions. This isn't an issue right now because wine ignores security and tends to look like Windows 98 or lower, anyhow. As we move towards a 2000/XP-like implementation (this is inevitable and unavoidable IMO if we want wine to remain useful), things start to get really awkward. So, User X wants to run Adobe Acrobat installer (which more-or-less works with wine right now). But it's the future, and wine looks like W2K. So when the installer gets to the stuff about installing printer drivers, it fails, forcing the user to become root to do the install. But root doesn't even have a ~/.wine directory! And if the user creates a symlink, all hell breaks loose because fake_windows becomes a mix of files owned by root and files owned by the user. I could concoct tons of similar examples. But I'll spare you the bandwidth.
In short: wine has relied on unix security historically, and it's been good enough, because wine security / permissions implementations have been nonexistant or exceedingly simple. Once we start getting more sophisticated about W32 security (and it seems to me, based on recent discussion, that this time is coming sooner than later), it's going to be inappropriate to continue with this approach, because we don't want to encourage users to do wine stuff as root.