Re: Services

[Shachar Shemesh]

Dustin Navea wrote:

--- Steve Langasek <[EMAIL PROTECTED]> wrote:

On Thu, Oct 24, 2002 at 08:08:49AM -0700, Dustin
Navea wrote:

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?

Unless wine has some suid capabilities (which it
shouldn't) this has no impact - wine runs in the account of

the

user who opens the
file (runs word).

I was actually thinking more from a read the file
standpoint, i.e if in the future wine runs as a
service with its own account, would wine be able

to

read the file after someone changed the file's

owner

from wine to, say user speeddy, or would it just

say

access denied and not let you read the file,

therefore

making you have to redo the permissions or make it
owned by wine again.

Just as wine should not be run as root, file i/o in
wine should NEVER be
done in a security context other than that of the
user running the Windows
app. Anything that would cause user data files to
be written out under a
different uid is broken.

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. 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. 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 if you use my proposed setup. speedy ran word with his user, all file access was done with his user. As such, all saves are done accordingly. If you will recall (just lookup my last message to the list), the user can only save stuff into ~speedy/wine (which translates, via symlink, to C:\Documents and Settings\speedy). As such, there is no problem as far as unix permissions are concerned.

If speedy next wants to edit the file from unix - no problem. He has full rw access to the file. Other people have access according to what speedy defined.

As for impersonation - in order to impersonate, the process must be able to obtain a token belonging to another user. If this is done via password, the standard unix system can be used (be it pam, su, or whatever). If by other means, a more elaborate system can be put in place, but I think we should postpone such discussions.

As for running/not running as root - the proper design should allow maximal functionality without root access, while allowing root access. This way we leave maximal control in the hands of the administrator of the machine.

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.

-Dustin

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

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/