Overriding the check for ownership of a prefix

[Scott Ritchie]

So, I believe I have a legitimate use case for ignoring this, and want 
to know what sort of patch would go forward.


Imagine a distro package containing a Windows game in the form of a 
read-only copy of an installed prefix (into, say, /opt).  When the user 
launches the app (via desktop file) this in turn launches a script that 
does the following:

1) Makes a temporary folder
2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the 
read-only packaged prefix in /opt, mounted in the temporary folder
3) Runs the app with WINEPREFIX= the temp folder
4) When the app is finished, unmounts the temp folder

This all works quite fine: new (or modified) files within the prefix get 
stored in ~/.appname, to be restored the next time the user runs the 
app.  Distinct users can run the app simultaneously, as they each have 
their own prefix.  Excess file-copying is avoided, as only the 
user-modified files need to be stored in the home folders.

There is one major snag, however: unionfs displays the owner as root 
until the user has modified/copied it.  This means Wine refuses to 
launch as the user with the "root-owned" prefix.  Simply commenting out 
this part of the code makes Wine work fine, however I'd like to be able 
to have a proper solution.


Would something like a command-line switch or environment variable be 
acceptable here?

Thanks,
Scott Ritchie


* Note that there is a problem with this setup if the app modifies the 
registry and we then need to update the prefix-default registry, but 
that's a different feature request

[Francois Gouget]

On Wed, 19 Sep 2012, Scott Ritchie wrote:
[...]
> There is one major snag, however: unionfs displays the owner as root until the
> user has modified/copied it.  This means Wine refuses to launch as the user
> with the "root-owned" prefix.

Wine checks the ownership of the $WINEPREFIX directory right? So 
wouldn't touching a file in $WINEPREFIX before starting Wine work? 
system.reg would be a good candidate. Alternatively, create/delete some 
other file.

-- 
Francois Gouget <fgouget(a)free.fr>              http://fgouget.free.fr/
                            1 + e ^ ( i * pi ) = 0

[Scott Ritchie]

On 9/20/12 3:07 AM, Francois Gouget wrote:
> On Wed, 19 Sep 2012, Scott Ritchie wrote:
> [...]
> > There is one major snag, however: unionfs displays the owner as root until the
> > user has modified/copied it.  This means Wine refuses to launch as the user
> > with the "root-owned" prefix.
>
> Wine checks the ownership of the $WINEPREFIX directory right? So
> wouldn't touching a file in $WINEPREFIX before starting Wine work?
> system.reg would be a good candidate. Alternatively, create/delete some
> other file.

Yes, unfortunately unionfs displays a sort of mixed permission 
structure: files are owned by the user once they are modified, but the 
hosting directory name itself can't be modified in this way, which is 
exactly what Wine checks.

[Scott Ritchie]

On 9/19/12 5:23 PM, Scott Ritchie wrote:
> So, I believe I have a legitimate use case for ignoring this, and want
> to know what sort of patch would go forward.
>
> Imagine a distro package containing a Windows game in the form of a
> read-only copy of an installed prefix (into, say, /opt).  When the user
> launches the app (via desktop file) this in turn launches a script that
> does the following:
>
> 1) Makes a temporary folder
> 2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the
> read-only packaged prefix in /opt, mounted in the temporary folder
> 3) Runs the app with WINEPREFIX= the temp folder
> 4) When the app is finished, unmounts the temp folder
>
> This all works quite fine: new (or modified) files within the prefix get
> stored in ~/.appname, to be restored the next time the user runs the
> app.  Distinct users can run the app simultaneously, as they each have
> their own prefix.  Excess file-copying is avoided, as only the
> user-modified files need to be stored in the home folders.
>
> There is one major snag, however: unionfs displays the owner as root
> until the user has modified/copied it.  This means Wine refuses to
> launch as the user with the "root-owned" prefix.  Simply commenting out
> this part of the code makes Wine work fine, however I'd like to be able
> to have a proper solution.

I have found a better solution: you can use standard FUSE options to 
mask the true owner such that it is always presented as the mounting 
user, even if the file is untouched.