Services

[Greg Turner]

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 :)

-- 
gmt

"Oh, and of course, the fastest way to dig
 a tunnel is to dig at both sides."
   -- The Linux Advanced Routing HOWTO