Services

[Vincent Béron]

Le jeu 24/10/2002 à 14:19, Dustin Navea a écrit :
> 
[Snip]
> 
> Thats not what I'm saying, what I'm saying is this:
> wine gets started by an initscript, so that you can
> run a .exe file by directly double-clicking on it. 

No need to setup a initscript for that, or have Wine run as a special
user. With the binfmt module properly setup, if your PE file is x, then
you can run it as any other ELF or script. Or, with Konqueror/Nautilus,
link .exe files to Wine. No need for a special account.

The need for a special account can come if you want to have a shared
fake (or real) Windows installation across all users on the system. And
even then, it's only because some applications will want write access to
system dirs. If all applications behaved properly (ie, not in a Win9x "I
can do whatever I want in c:\windows" fashion), then it'd be even
simpler to do, and Wine can probably already cope with that.

> User Speeddy double-clicks winword.exe, creates a .doc
> file adds a few lines and saves it.  When it gets
> saves, it gets saves to the *nix fs with owner and
> group wine.  Say later on he wants to try out kword. 
> So he goes to open it in kword, but since he isnt user
> wine or part of group wine, he gets access denied.  So
> he goes and changes the owner/group to
> speeddy/speeddy, oepns the file in kword, adds a few
> more lines, and saves it.  Then he decides he doesnt
> like kword and goes to run it in ms word again. 
> Access denied again because it isnt owned by
> user/group wine, it is owned by user/group speeddy. 
> So he has to go redo the owner/group again.  That is
> too much of a hassle.

Small question: how the wine user could get write access to $HOME? (your
proposition below is not a good idea IMHO)

> Wine could be an almost
> all-powerful account.  Where root is god, wine could
> be king. root can rwx anything, wine can rw
> anything...

Not sure at all it's a good idea. Expecially the rw thing, for which
you'll need kernel support (which I don't think would be integrated in
the official one).

> 
> I know the above example is not very common, but it
> can happen if we have wine running in it's own
> account, unless the wine account is setup as explained
> in the end of above paragraph.

I think what the discussion diverged to is how to setup (securely) Wine
so that it's easy to install system-wide (accessible to all users) a
program/driver.

The easy solution would be to setup a wine-user user, put the
fake_windows in /usr/local/fake_windows, have all files rw-rw-r-- (x for
.exe if using binfmt), and have wine-user owner on all those files.You
install/remove software using only that user (since he only has write
access). That way, it looks a lot like in most computer labs where the
user cannot (or should not) access the system/apps, but is free in his
own account.

Also, remember that a lot of Windows apps have difficulties coping with
multiple users (think permissions), and even more with multiple
simultaneous uses, although things like TerminalServer helps on that
front to keep developers in check.

> 
> -Dustin
> 
> P.S. have I confused everyone enough yet? ;-P

No me (yet :)

Back to the services part, I agree with Alexandre: do we have something
needing services now, and is it worth it to support all of it.

Vincent