--- Martin Wilck Martin.Wilck@fujitsu-siemens.com wrote:
This thread has immediately jumped to the future-development discussion :-)
In the first place, I simply wanted to know what the current rudimentary "service" implementation (which simply calls CreateProcess) is good for, and whether anybody knows about Windows or Winelib programs running on Wine that actually use this API.
I think this simple approach could take us quite far without even thinking about changing user accounts, acquiring extra Unix capabilities, etc.
I have to agree with Martin here.
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.
Never, never, never, never, never run wine as root!!
they could just invoke their executable from an init script; that's more "service" like anyhow.
I would say the best way to see what this is like (in case you dot understand) would be to look at postgresql. It runs as user postgresql no matter who you are logged in as, and that user/group has only the ability to do what postgresql needs to do, nothing more nothing less, so there is very little/no threat of a compromise there.
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
- 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.
I totally agree with this approach. That way, you can be logged in as whoever you want to be logged in as, and if you wanted to run say word, then it would be run with uid/gid wine and therefore any files you save would only be able to do things on the wine account.
Another potential problem popped into my head though, and that is:
what if someone edits the initscript to where wine runs as root (or someone compromises the server and does it), or what if someone just changes the owner/group on the file (like a word doc), and then tries to run it with wine, what happens then?
(all of this see below, this pertains to both this section) (and)
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 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.
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.
(the one above here)
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.
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?
Martin
__________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/