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