Services

Shachar Shemesh wine-devel at sun.consumer.org.il
Thu Oct 24 14:47:10 CDT 2002


Dustin Navea wrote:

>--- Steve Langasek <vorlon at dodds.net> 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/
>
>  
>







More information about the wine-devel mailing list