Services

[Greg Turner]

On Thursday 24 October 2002 12:30 am, Dimitrie O. Paun wrote:
> On October 22, 2002 12:24 pm, Martin Wilck wrote:
> > The fact that wine cannot change user personalities and is lacking most
> > of the NT security concepts makes services pretty useless.
>
> I was thinking, can't we somehow use stuff like sudo(8) to accomplish
> that? I personally haven't used sudo(8), but if we do support services,
> we have to integrate nicely with the Unix world, IMO.

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, they could just invoke their executable from an
init script; that's more "service" like anyhow.

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.  So, for example:

  Installing a service == create an init script
  Set service as "automatic" == put the script in the default runlevel
  Uninstall a service == remove from all runlevels & remove init script
  ... etc.

Now, we create "wineservices.exe", create sudo permissions on this
for the appropriate users, and implment it very, very carefully.

Needless to say, this is a very sketchy proposition.  It is "correct," 
from a certain perspective; it's also very, very likely that people
will use it to create huge gaping security holes in their system, like
basically allowing themselves to run arbitrary scripts as root with
very little effort, and then, inevitably, wine will get a bad rap as a result.

I'm starting to lean towards the opinion that if these security and
identity aspects start to be implemented, then wine should just have its
own user database, kind of like samba.  So, for example, we create
a database that maps unix users onto wine users, with flexible percieved
windows permissions within the wine sandbox, or, in server environments,
wine maps unix accounts onto domain accounts from the server.

This way, a user could "be administrator" within wine, but not be root
on their unix box.  If we just thunk wine security down to unix security,
we are ignoring a very important difference between Windows and UNIX:
the vast majority of unix users don't run as root; whereas the majority
of Windows users /do/ run as Administrator or some equivalent.

An example: wine users need to run installers.  Installers, as often as not,
need Administrator permissions.  This isn't an issue right now because
wine ignores security and tends to look like Windows 98 or lower,
anyhow.  As we move towards a 2000/XP-like implementation (this is
inevitable and unavoidable IMO if we want wine to remain useful),
things start to get really awkward.  So, User X wants to run Adobe
Acrobat installer (which more-or-less works with wine right now).
But it's the future, and wine looks like W2K.  So when the installer
gets to the stuff about installing printer drivers, it fails, forcing the user
to become root to do the install.  But root doesn't even have a ~/.wine
directory!  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.

In short: wine has relied on unix security historically, and it's been good 
enough, because wine security / permissions implementations have been
nonexistant or exceedingly simple.  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.

-- 
gmt

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