On Thursday 24 October 2002 04:12 am, Martin Wilck wrote:
This thread has immediately jumped to the future-development discussion
:-)
sorry. my fault. I guess that stems from me not having a good answer to the actual question you were asking :)
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,
Wine shouldn't run as root. I don't see strong arguments against running a wine service in a dedicated non-root Unix user account, though.
agreed.
they could just invoke their executable from an init script; that's more "service" like anyhow.
That has nothing to do with the Windows service API and won't help you a bit trying to port a Windows app that uses that API.
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.
IMO a bad idea, this comes down to real root access for wine. I'd rather install a single init script starting a daemon that
also agreed; I was just playing devil's advocate.
- changes uid/gid to a dedicated unix account with non-root privileges,
- (perhaps) does a chroot(),
- starts wine.
The wine process would then start all registered Windows services in his environment. An "autostart" service would mean that the process is started when the first wine process starts. To stop the services, we'd need a "shutdown" application of some sort.
Obviously this would require wineserver calls, no idea if a server protocol extension would be necessary.
Controlling these services would require a su(1) to the service account and starting a windows service-control executable.
this is a totally viable approach. It does begin to beg the question of whether wine would have to move from per-user installations to shared installations... but those issues are not insurmountable.
This way, a user could "be administrator" within wine, but not be root on their unix box.
If you think about it, this is exactly the situation that we have now, and it's not so bad after all. No restrictions in the Win environment, but normal user privileges from the Unix perspective.
this is currently more a side-affect of a missing security implementation than a result of clever engineering. I guess what I mean above is that, as we implement security features, we need to preserve this capability, and it seems most agree.
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.
This could be solved by a system-wide wine installation with its own security handling. All installed files would (in the Unix sense) belong to the user the wine process is running as. For very good reasons that user shouldn't be root.
yup. now we have big open questions, however: what parts of wine should be "shared" and owned by the "wine" user? What parts are per user? etc... That doesn't mean I don't like this approach, btw. But it's a significant change, and would take some careful thought and some significant time at the drawing board.
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.
I can't follow you here - **wine must not be run as root**, and we can't do anything but repeat that over and over again, whether or not we implement services and/or security management in wine.
? I'm afraid I don't follow either. Doesn't matter; we seem to be in agreement about wine-as-root. I would make one exception: if certain things need to happen as different unix users, there is going to have to be some process running which is capable of executing "become user" calls. So, for example, I could imagine something like
rootwineserver (runs as root. does almost nothing but spawn wineservers) | +-- wineserver -u 'fred' (runs as fred) | +-- wineserver -u 'bob' (runs as bob) | +-- wineserver -u 'winesystem' (runs as winesystem; rough equiv. to NT SYSTEM acct.) | +-- wineservices (runs as winesystem) | +-- service 1 (runs as winesystem) | +-- service 2 (runs as winesystem)
This is something like how sshd works. rootwineserver could be a pure-unix program that runs as root, and takes care of a very small set of truly priveleged operations (like listening on priveleged ports and spawning processes as other users). The wineserver -u winesystem process could do "virtually priveleged" operations which require priveleged access in windows but not unix (priveleged registry access, authentication, etc).
Even the above model is too simple if, for example, we truly want to do impersonation, or allow services to start as different users as configured in the registry, etc. Some of these features might require a disconnect between the concept of unix process parentage and windows process parentage, since, for example, for wineservices to launch a service process as 'fred', the unix process would probably need to be launched by rootwineserver.
I don't mean to suggest an implementation, but just to point out that, if properly implemented, "no wine stuff as root" doesn't need to be an absolutely hard-and-fast rule; personally I would not object to a rule of "absolutely as little wine stuff as root as possible," sometime down the road.
In any case, if a future wine did its own security management, the users and groups must still map to Unix users and groups - if not, how would such a future wine determine the access rights of a Unix file that only shows Unix user/group permissions?
Yes, but the operative term is 'map': samba provides an example of how this could be done. Frankly, it is confusing and a bit of a hassle, but a little database that maps unix users to "windows" users can go a long way towards addressing certain problems. The counterargument to such an approach is that it creates unneccesary confusion, complexity, and administrative hassles (and samba does, indeed suffer from these symptoms, but not unreasonably so IMHO).
Anyhow, talk is cheap so I will shut up about his now, before I end up writing code :)