I think Wine should, and CAN, do without privelege escalation at all.
Let's look at some of the examples presented here. If we want to give a multi user Windows experience that is compatible with the multi-user Unix experience, our trust model must be comperable. My view of such a case is this: Wine is installed on the system. This means that there is a directory called "/usr/wine", inside of which you can find "/usr/wine/windows", "/usr/wine/Program Files" etc. Permissions on this directory are set according to the unix standard - i.e. - only admins.
Then again (assuming W2K compatibility) - you get "/usr/wine/Documents and Settings/dimi", that is a symlink to "/home/dimi/wine". It goes without saying that, as far as the Windows applications, "C:\Documents and Settings\dimi" is the directory, writable to the proper user.
Now, you need to be administrator to install a new program. Nothing new about that. If the admin want's to change that, she can set a group to the entire /usr/wine directory structure, and give that group write permission. There are still some security issues with this model. The wine server probably needs to be SUID to server everyone, etc. But still, that is a model that works. Besides, the server does not need to be SUID root, it can have a special user for that purpose. This is probably also required for registry access, if we want to enforce registry ACLs - we can't have a malicious user by pass the wine permissions by simply accessing the file directly, so the system registry file must not be readable by normal users (hence the need for suid on the server).
As for printer drivers, and services at large - there is a major question here of whether we wish Wine services to be able to server non-wine processes. If the answer is "yes", as is probably the case with an Adobe PDF printer driver, or with a winmodem's driver, root must install them.
If the answer is "no", then there is no breaking of the model. With the directory structure as defined today, each user can install it, claiming full admin rights over the loca directory structure. Of course, the new adobe's printer driver only serves his programs.
There is one problem with this model that has to do with windows programs that require admin in order to RUN. I know of a few of those. Some of them simply require DirectX, and these don't seem like a problem in Wine. Others require file access, and I was considering writing a program for Windows that will work around that by API remapping. I think it will be possible to make these programs work without breaking permissions. If so, it will certanly be easier to implement in Wine than in Windows.
Shachar
Greg Turner wrote:
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.
Actually, I think PAM is a more apropriate answer to this. I am saying this without thorough knowledge of PAM, though.
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.