Services

[Martin Wilck]

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.

> 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.

> 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

- 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 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.

> 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

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy