Services

[Dustin Navea]

--- Martin Wilck <Martin.Wilck at 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/