Re: UID/GID support
On Thu, Feb 10, 2011 at 8:06 AM, sf...@users.sourceforge.net wrote:
find /srv/wine/wine-Diablo_II -type d -exec chmod ugo+rwX '{}' \;
find /srv/wine/wine-Diablo_II -type f -exec chmod ugo+rwX '{}' \;
I'd suggest you to do it carefully.
- giving unnecessary permission bits can be a problem for security.
- As you did chown -R, you will be able to run chmod -R here.
With the chmod permission changes the chown is not necessary. The ro
branch files in the squashfs are owned by wineadmin. The permissions
are not a problem since the squashfs is a ro loop mount. Any writes
will be to the aufs rw branch that the user owns.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
Jeff Hanson: With the chmod permission changes the chown is not necessary. The ro branch files in the squashfs are owned by wineadmin. The permissions are not a problem since the squashfs is a ro loop mount. Any writes will be to the aufs rw branch that the user owns. If you have very important file for security such like /etc/passwd, then the permission bits in the ro squashfs can be a problem. As you know, passwd file is world-readble but only an administrator can write. If you set it world writable in the lower ro branch and provide users aufs, then users can modify the file in aufs. Of course it is limited within the rw branch and aufs world, and highly depending upon the meaning of the file. And I just pointed out you may be able to -R for chmod. J. R. Okajima -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
Jeff Hanson: The aufs mount point. That is what the users will be working with. Do you mean only the directory? If so, aufs does copyup the dir only, and I don't think it fills up the rw branch. Some is the problem. I can't predict which files out of the ro ::: Right. How many files will be copied-up? will be a problem. But I don't think the problem will be solved even if aufs supports uid-mapping (or faking). Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example ::: Ok, you don't want to spend 11GB, and you could reduce to 2.3GB by mounting aufs for each user. For deployment, I copy .wine-Diablo_II to /srv/wine/.wine-Diablo_II and remove symlinks specific to wineadmin which are for special folders like My Documents. Diablo license keys in this copy of the Wine registry are purged. All files/directories are owned by wineadmin with file permissions of 644 (rw-r--r--) and directory permissions of 755 (rwx-r-xr-x). Next I need to install a popular mod, Median XL ::: Ok, you made changes to the original Diablo II files with changing the dir. While I don't know where the original ~wineadmin/.wine-Diablo_II went, but I hope users who are playing Diablo II right now can keep playing. By the way, if you want, you may be able to provide both of the original Diablo II and Median XL-ed one by aufs. - you already have $srv/Diablo_II which contains the original one. create a new $srv/Diablo_II_Median_XL with keeping $srv/Diablo_II unchanged. mkdir $srv/Diablo_II_Median_XL mount -t aufs -o br:$srv/Diablo_II_Median_XL:$srv/Diablo_II \ none $srv/Diablo_II_Median_XL (apply Median XL and the changed files are stored in $srv/Diablo_II_Median_XL) mount -o remount,ro $srv/Diablo_II_Median_XL (now you have $srv/Diablo_II and $srv/Diablo_II_Median_XL which are to be shared and provied to users. and $srv/Diablo_II_Median_XL holds the diff from the original only) - provide users the original. mount -t aufs -o br:~user/Diablo_II:$srv/Diablo_II none ~user/Diablo_II - provide users the Median XL-ed one. mount -t aufs -o br:~user/Diablo_II_Median_XL:$srv/Diablo_II_Median_XL \ none ~user/Diablo_II_Median_XL Additionally, because you may want to keep the shared files unchanged, there are options to make them readonly. For example, make an ext2 image. dd if=/dev/null of=Diablo_II.ext2 bs=... count=... mkfs -t ext2 Diablo_II.ext2 mount -o loop Diablo_II.ext2 /mnt cp -pr $srv/Diablo_II /mnt umount /mnt losetup -r /dev/loop0 Diablo_II.ext2 mount -o ro /dev/loop0 $srv/Diablo_II Now you have $srv/Diablo_II dir from a single file Diablo_II.ext2. And the mount option 'ro' is specified. Also /dev/loop0 is bound as readonly too (losetup -r). So under $srv/Diablo_II no one can make modification even if you set all permissions to world-writable. Of course, you can make any filesystem instead of ext2. You may want to try isofs, squashfs or something. The problem is that none of this actually functions with the current aufs. The /home/administrator/.wine-Diablo_II directory and files are owned by wineadmin so the administrator account can't modify the Wine registry or any files even though it owns /home/administrator/.wine-Diablo_II_rw. The only solution is to ::: Then I'd suggest you to try the approach like above, world-writable files and readonly mount for the ro branch. Correct although in my example the ro branch is owned by wineadmin. It doesn't matter. J. R. Okajima -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Tue February 8 2011, Jeff Hanson wrote: On Tue, Feb 8, 2011 at 3:59 PM, Michael S. Zick a...@morethan.org wrote: That is a property of inode file systems - only one location for ownership. Symbolic link chain at the directory name level - Hard links are many names-to-single inode - with one location for ownership. There are file systems (on non-*nix systems) that can clone the data branch independent of the meta-data - just not under *nix (I.E: Linux). The work around for that inherent property of inode file systems is the various systems of ACL meta-data. I.E: What you seem to want is a per-user Access Control List (ACL) that is created on-demand (rather than the data copied on-demand). Should not result in the entire directory contents, only the files that where changed. And nothing except a rootkit should be writing to executables. Actually I just want to fake user ownership in the mount point so that userspace applications (like Wine) can write to it (which ends up in the rw branch). Currently the ownership and permissions come from the ro branch which the user doesn't have write permission to. Wine can't/won't write to the mount point even if the user has ownership of the rw branch. Since the ro branch is set ro and owned by a different account (or root) and the aufs mount point in the user's directory is mounted by root (fstab or pam_mount), there is no risk to the system by faking different ownership there. Any writes are going to be in the rw branch. It does work when looped through CIFS/SMB but that's an overcomplicated (and ugly due to the Gnome gvfs bug) solution. I'm not familiar with ACL capabilities on Linux. Does aufs support ACLs? The web page section seems to indicate no with Features or just an idea in the future (see also design/*.txt), http://aufs.sourceforge.net/ Sorry if what I wrote sounded like auFS supported stacked Access Control Lists (ACLs). I don't think it does, I don't think it should. The problems with trying to consolidate changes in multiple ACL controlled rw branches back into the single (master) ro branch seems mind-boggling (to me). For that use case, jro's suggestion of a custom, fuse based, file system layer that translates the current-user-specfic section of the master file's ACLs into current-user permissions may be what you need. As a WAFG, I suspect it would not be a trivial file system to write. ;-) You might also have to make some custom extensions to the ACL entries to help your fuse based system deal with things like: user-1 has mod-x, version-10 installed and user-3 has mod-x, version-15 installed. I.E: Manage per-user symbolic links for the file(s) related to mod-x based on the meta-data entries of the master's ACLs. As to ACL support in Linux - I think most of the major file systems have full ACL support (as a kernel compile time option - usually turned off). At this point I have to depend on my memory (a flaky thing to depend on) - I think that either (both?) VMS and Plan-9 file systems can do what you need for access control - but stackable under Linux - I think not. ;-) Mike Keep in mind that you don't want to disable the handling of single use restrictions for executables which are licensed that way. Many commercial programs that can be run with Wine on a multi-user machine are not (commonly) licensed for multiple concurrent use on a single machine. A common example is any Microsoft DLLs you let Wine access. They are almost always single use per machine licensed. Most Linux desktops have switch-user functionality so multiple users can be logged in but only one has keyboard/mouse access. A lot of older applications are supported well enough in Wine that additional dlls are not needed. Any with licensing that strict will have DRM with centrally registered key servers so concurrent usage license violations within a single site are unlikely. With internally developed applications the licensing is not an issue. Many businesses have such legacy applications that function on Wine and aren't worth rewriting. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
Michael S. Zick: For that use case, jro's suggestion of a custom, fuse based, file system la= yer that translates the current-user-specfic section of the master file's ACLs into current-user permissions may be what you need. As a WAFG, I suspect it would not be a trivial file system to write. ;-) Maybe you are right. :-) But what I suggested to him is different a little bit. Since he mentioned about sshfs (fuse based), I am thinking to extract the related parts from sshfs and create a new fuse based one. Doesn't it sound easier than developing fuse based ACL converter? J. R. Okajima -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Wed, Feb 9, 2011 at 3:34 AM, sf...@users.sourceforge.net wrote: Jeff Hanson: The aufs mount point. That is what the users will be working with. Do you mean only the directory? If so, aufs does copyup the dir only, and I don't think it fills up the rw branch. mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_rw=rw:/srv/wine/.wine-Diablo_II=ro none /home/administrator/.wine-Diablo_II chown -R administrator:administrator /home/administrator/.wine-Diablo_II Some is the problem. I can't predict which files out of the ro ::: Right. How many files will be copied-up? will be a problem. But I don't think the problem will be solved even if aufs supports uid-mapping (or faking). I don't fully understand how aufs handles ownership and permissions. From what Mike said it seems it just passes them through from the branch filesystems. What happens if the same file exists in two ro branches and they have different ownership? Does the order of the branches when mounting determine which one gets priority in the mount point? Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example ::: Ok, you don't want to spend 11GB, and you could reduce to 2.3GB by mounting aufs for each user. Correct. It saves space and with some scripting it should save deployment time also. Next I need to install a popular mod, Median XL ::: Ok, you made changes to the original Diablo II files with changing the dir. While I don't know where the original ~wineadmin/.wine-Diablo_II went, but I hope users who are playing Diablo II right now can keep playing. The shared copy is now in /srv/wine and users don't have access to the original in /home/wineadmin. I just moved the original so I can reuse the same path for a new mount point. The goal is to get the diff of the original Diablo file structure (now mounted through aufs from /srv/wine) and Median XL in the new rw branch. By the way, if you want, you may be able to provide both of the original Diablo II and Median XL-ed one by aufs. - you already have $srv/Diablo_II which contains the original one. create a new $srv/Diablo_II_Median_XL with keeping $srv/Diablo_II unchanged. mkdir $srv/Diablo_II_Median_XL mount -t aufs -o br:$srv/Diablo_II_Median_XL:$srv/Diablo_II \ none $srv/Diablo_II_Median_XL (apply Median XL and the changed files are stored in $srv/Diablo_II_Median_XL) mount -o remount,ro $srv/Diablo_II_Median_XL (now you have $srv/Diablo_II and $srv/Diablo_II_Median_XL which are to be shared and provied to users. and $srv/Diablo_II_Median_XL holds the diff from the original only) - provide users the original. mount -t aufs -o br:~user/Diablo_II:$srv/Diablo_II none ~user/Diablo_II - provide users the Median XL-ed one. mount -t aufs -o br:~user/Diablo_II_Median_XL:$srv/Diablo_II_Median_XL \ none ~user/Diablo_II_Median_XL That is another way of doing the same thing I described. I think I used the copy approach because I was concerned that the .wh.* files in the rw branch would cause problems if the branch was reused as an ro branch. Additionally, because you may want to keep the shared files unchanged, there are options to make them readonly. For example, make an ext2 image. dd if=/dev/null of=Diablo_II.ext2 bs=... count=... mkfs -t ext2 Diablo_II.ext2 mount -o loop Diablo_II.ext2 /mnt cp -pr $srv/Diablo_II /mnt umount /mnt losetup -r /dev/loop0 Diablo_II.ext2 mount -o ro /dev/loop0 $srv/Diablo_II Now you have $srv/Diablo_II dir from a single file Diablo_II.ext2. And the mount option 'ro' is specified. Also /dev/loop0 is bound as readonly too (losetup -r). So under $srv/Diablo_II no one can make modification even if you set all permissions to world-writable. Of course, you can make any filesystem instead of ext2. You may want to try isofs, squashfs or something. That is not something I though of and may solve my problem. It could also allow me to use squashfs to reduce the size further. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
Jeff Hanson: chown -R administrator:administrator /home/administrator/.wine-Diablo_II Because you add -R, chown handles all of the specified dir, the files and the sub-dirs under it recursively and unconditionally. But what I suggested is to chown only the file which a user is going to modify. I don't fully understand how aufs handles ownership and permissions. From what Mike said it seems it just passes them through from the branch filesystems. What happens if the same file exists in two ro branches and they have different ownership? Does the order of the branches when mounting determine which one gets priority in the mount point? (from the aufs manual) -- The test for permission bits has two cases. One is for a directory, and the other is for a non-directory. In the case of a directory, aufs checks the permission bits of all existing directories. It means you need the correct privilege for the directories including the lower branches. The test for a non-directory is more simple. It checks only the topmost inode. -- J. R. Okajima -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Wed, Feb 9, 2011 at 8:38 PM, sf...@users.sourceforge.net wrote:
Jeff Hanson:
chown -R administrator:administrator /home/administrator/.wine-Diablo_II
Because you add -R, chown handles all of the specified dir, the files
and the sub-dirs under it recursively and unconditionally. But what I
suggested is to chown only the file which a user is going to modify.
Because of the complexity of the applications, number of files, and
built-in updaters, I can't predict which files need to be modified so
I have to assume all of them.
(from the aufs manual)
--
The test for permission bits has two cases. One is for a directory,
and the other is for a non-directory. In the case of a directory, aufs
checks the permission bits of all existing directories. It means you
need the correct privilege for the directories including the lower
branches.
The test for a non-directory is more simple. It checks only the
topmost inode.
--
Ownership handled the same as permissions?
I tried an ext2 image. It worked but is complicated to set up as I
have to accurately determine the size of the application files when
creating it else it either doesn't have enough space or wastes space.
I tried squashfs and found it was much easier to create as the
mksquashfs tool takes the source directory, compresses it as it reads
and writes it to the image file (which it creates). Plus it saves
space with compression although only a little with Diablo II as its
media files are already compressed (2GB vs. 2.3GB).
find /srv/wine/wine-Diablo_II -type d -exec chmod ugo+rwX '{}' \;
find /srv/wine/wine-Diablo_II -type f -exec chmod ugo+rwX '{}' \;
mksquashfs /srv/wine/.wine-Diablo_II /srv/wine/Diablo_II-sqfs.img
mount /srv/wine/Diablo_II-sqfs.img /srv/wine/wine-Diablo_II-sqfs -t
squashfs -o ro,loop
mount -v -t aufs -o
br:/home/administrator/.wine-Diablo_II_rw=rw:/srv/wine/wine-Diablo_II-sqfs=ro
none /home/administrator/.wine-Diablo_II
Gnome gvfs doesn't show the mounted squash file so I avoid that bug as well.
This solves my problem. Thanks!
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Fri, Feb 4, 2011 at 4:03 PM, Jeff Hanson jhanso...@gmail.com wrote: Users can't run chown because they are not root. Another problem is that the CIFS mounts show up in Gnome/Nautilus as mounted volumes. Since these are ro mounts that only exist for the UID change they aren't useful to the user and just make a mess of the desktop and Nautilus places sidebar. The aufs mount point is what the user needs. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Sun, Feb 6, 2011 at 9:58 PM, sf...@users.sourceforge.net wrote: How about writing a wrapper? Allow chown after some tests. - the target path is aufs, or /home/$USER in your case? - the target uid is $USER - etc The warpper may be implemented suid-ed, or customized /etc/sudoers. I can do that easily and it would only work for a single-user desktop with one user logged in. If there is more than one simultaneous user, or if the ro branch is located on a server that is sharing with a protocol that doesn't have UID/GID override support (like NFS) then this method doesn't really function. There is also the problem of not wanting to trust users with shared executables that they can write to. As Wine becomes more compatible with Windows it will be more vulnerable to malware and the separation of rw data between users is crucial. Allowing them to chown means that anything can be written to the files from their account and the users of other accounts will be executing (and possibly writing to) the same files.. You may want to try fuse, nfs or any other fs which has uid-mapping feature. After some considerations, I could understand why you want such feature in aufs. But as I wrote first, I don't think it is a feature of stackable filesystem. Aufs should follow and should not disturb the native behaviour of brach fs. I did look into funionfs but it had a lot of bugs and development stopped back in 2005 pending a rewrite. I reported a bug about the problem with SMB/CIFS mounts being displayed in Nautilus even if the mount point is a hidden directory but the initial response wasn't enthusiastic: https://bugzilla.gnome.org/show_bug.cgi?id=641569 I understand your position. A filesystem that does nothing more than change UID/GID/ACLS/permissions would be perfect but I don't know of any. Seems like it would be a great feature for a rootkit :D I'll keep looking for other solutions. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Tue, Feb 8, 2011 at 2:44 AM, sf...@users.sourceforge.net wrote: Users have their own rw branch individually, don't they? chwon makes the file copied-up in aufs. So it never affect other users. Tried that. The result is that the rw branch ends up with the entire data of the ro branch. It seems that aufs copies the entire file to the rw branch even if only the ownership changes. Effectively: aufs + chown = cp which eliminates my primary reason for using aufs which is to save storage space by eliminating the need to replicate the entire contents of the application directory in each users' home directory. Then I am afraid the approach you wrote faking uid internally will be insecure either. No. From the user's perspective, only the file ownership within the aufs mount point appears to change. The real ro branch remains owned by root. They can modify the files as if they owned them but the changes end up in the rw branch. The ro branch is not affected. I'd suggest you to develop a fuse based one. I don't think that shell scripts can be used for that so I can't do much until I learn C or find someone willing to write it for me. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Tue February 8 2011, Jeff Hanson wrote: On Tue, Feb 8, 2011 at 2:44 AM, sf...@users.sourceforge.net wrote: Users have their own rw branch individually, don't they? chwon makes the file copied-up in aufs. So it never affect other users. Tried that. The result is that the rw branch ends up with the entire data of the ro branch. It seems that aufs copies the entire file to the rw branch even if only the ownership changes. Effectively: aufs + chown = cp That is a property of inode file systems - only one location for ownership. Symbolic link chain at the directory name level - Hard links are many names-to-single inode - with one location for ownership. There are file systems (on non-*nix systems) that can clone the data branch independent of the meta-data - just not under *nix (I.E: Linux). The work around for that inherent property of inode file systems is the various systems of ACL meta-data. I.E: What you seem to want is a per-user Access Control List (ACL) that is created on-demand (rather than the data copied on-demand). which eliminates my primary reason for using aufs which is to save storage space by eliminating the need to replicate the entire contents of the application directory in each users' home directory. Should not result in the entire directory contents, only the files that where changed. And nothing except a rootkit should be writing to executables. Keep in mind that you don't want to disable the handling of single use restrictions for executables which are licensed that way. Many commercial programs that can be run with Wine on a multi-user machine are not (commonly) licensed for multiple concurrent use on a single machine. A common example is any Microsoft DLLs you let Wine access. They are almost always single use per machine licensed. Mike Then I am afraid the approach you wrote faking uid internally will be insecure either. No. From the user's perspective, only the file ownership within the aufs mount point appears to change. The real ro branch remains owned by root. They can modify the files as if they owned them but the changes end up in the rw branch. The ro branch is not affected. I'd suggest you to develop a fuse based one. I don't think that shell scripts can be used for that so I can't do much until I learn C or find someone willing to write it for me. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Tue, Feb 8, 2011 at 3:59 PM, Michael S. Zick a...@morethan.org wrote: That is a property of inode file systems - only one location for ownership. Symbolic link chain at the directory name level - Hard links are many names-to-single inode - with one location for ownership. There are file systems (on non-*nix systems) that can clone the data branch independent of the meta-data - just not under *nix (I.E: Linux). The work around for that inherent property of inode file systems is the various systems of ACL meta-data. I.E: What you seem to want is a per-user Access Control List (ACL) that is created on-demand (rather than the data copied on-demand). Should not result in the entire directory contents, only the files that where changed. And nothing except a rootkit should be writing to executables. Actually I just want to fake user ownership in the mount point so that userspace applications (like Wine) can write to it (which ends up in the rw branch). Currently the ownership and permissions come from the ro branch which the user doesn't have write permission to. Wine can't/won't write to the mount point even if the user has ownership of the rw branch. Since the ro branch is set ro and owned by a different account (or root) and the aufs mount point in the user's directory is mounted by root (fstab or pam_mount), there is no risk to the system by faking different ownership there. Any writes are going to be in the rw branch. It does work when looped through CIFS/SMB but that's an overcomplicated (and ugly due to the Gnome gvfs bug) solution. I'm not familiar with ACL capabilities on Linux. Does aufs support ACLs? The web page section seems to indicate no with Features or just an idea in the future (see also design/*.txt), http://aufs.sourceforge.net/ Keep in mind that you don't want to disable the handling of single use restrictions for executables which are licensed that way. Many commercial programs that can be run with Wine on a multi-user machine are not (commonly) licensed for multiple concurrent use on a single machine. A common example is any Microsoft DLLs you let Wine access. They are almost always single use per machine licensed. Most Linux desktops have switch-user functionality so multiple users can be logged in but only one has keyboard/mouse access. A lot of older applications are supported well enough in Wine that additional dlls are not needed. Any with licensing that strict will have DRM with centrally registered key servers so concurrent usage license violations within a single site are unlikely. With internally developed applications the licensing is not an issue. Many businesses have such legacy applications that function on Wine and aren't worth rewriting. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
Jeff Hanson: Tried that. $BB (BThe result is that the rw branch ends up with the entire data of the ro branch. $BB (BIt seems that aufs copies the entire file to the rw branch even if only the ownership changes. $BB (BEffectively: aufs + chown = cp which eliminates my primary reason for using aufs which is to save storage space by eliminating the need to replicate the entire contents of the application directory in each users' home directory. What did you chown? My asummption is - you have all common files in the ro branch. (if your common files should be run by multiple users at the same time as Michael S. Zick pointed, then you should not do that) - users customize some of files, and these files are put in his rw branch. - finally the rw branch has only the difference. If the difference is so large and the rw branch cannot have all of them due to its space, then you just need to expand the size of rw branch. If you have chwon-ed the common files, then that must be unnecessary. No. $BB (BFrom the user's perspective, only the file ownership within the aufs mount point appears to change. $BB (BThe real ro branch remains owned by root. $BB (BThey can modify the files as if they owned them but the changes end up in the rw branch. $BB (BThe ro branch is not affected. Aufs never write to the ro branch. If it happens, it must a bug. Jeff, I don't think your discussion style is good. You send mails to me directly, personally and I replied to you. Later you forwarded your messages only to the aufs ML. It might be your simple failure of operating mail software. But it is not only once. I won't reply to your personal mails. J. R. Okajima -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
Re: UID/GID support
On Tue, Feb 8, 2011 at 10:34 PM, sf...@users.sourceforge.net wrote: What did you chown? The aufs mount point. That is what the users will be working with. They could access the rw branch directly since it is in their home but that is unlikely since it is hidden. My asummption is - you have all common files in the ro branch. (if your common files should be run by multiple users at the same time as Michael S. Zick pointed, then you should not do that) - users customize some of files, and these files are put in his rw branch. - finally the rw branch has only the difference. Some is the problem. I can't predict which files out of the ro branch they will want to modify. Many Windows applications have their own on-line update utilities for patching so any file can be changed by the user account. With games there are many third-party modifications that can be added and I can't tell which games the users will play or which mods they will add. If the difference is so large and the rw branch cannot have all of them due to its space, then you just need to expand the size of rw branch. If you have chwon-ed the common files, then that must be unnecessary. Using Diablo II (http://en.wikipedia.org/wiki/Diablo_II) as an example of installation for multiple users, this is what I want to do. To function without the CDs a full installation is needed which is about 2.2GB total. With five users that is 11GB for one game. If I use aufs and share one installation then it's closer to 2.3GB total for all five users. I have a special user account wineadmin which is identical to other user accounts except that it owns /srv/wine. I login as wineadmin and I create a directory ~/.wine-Diablo_II and install Diablo II into it (WINEPREFIX=/home/wineadmin/.wine-Diablo_II). The latest Diablo updates and patches are applied. For deployment, I copy .wine-Diablo_II to /srv/wine/.wine-Diablo_II and remove symlinks specific to wineadmin which are for special folders like My Documents. Diablo license keys in this copy of the Wine registry are purged. All files/directories are owned by wineadmin with file permissions of 644 (rw-r--r--) and directory permissions of 755 (rwx-r-xr-x). For each user (administrator in this example) I create ~/.wine-Diablo_II and ~/.wine-Diablo_II_rw and mount the shared copy with aufs: mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_rw=rw:/srv/wine/.wine-Diablo_II=ro none /home/administrator/.wine-Diablo_II Wine symlinks for administrator are recreated in ~/.wine-Diablo_II/dosdevices and ~/.wine-Diablo_II/drive_c/users/administrator. Registry entries for wineadmin in the administrator copy of the registry (~/.wine-Diablo_II/*.reg) are fixed with sed and regex. XDG/fdo menu entries are added in ~/.config/menus and ~/.local/share/applications. The game is started and new license keys are entered. This process is repeated for each user. When a user updates Diablo II from its built-in updater, the changes only affect them as they are contained in their rw branch. When they play the game, the save files are located in the Diablo II application directory in ~/.wine-Diablo_II/drive_c/Program Files/Diablo II/save/ and game settings are either in *.ini files or in the Wine registry. Next I need to install a popular mod, Median XL (http://modsbylaz.hugelaser.com). It consists of a replacement Patch_D2.mpq file. Because it greatly changes and complicates the game, I need to maintain the original installation for beginners. I log back into wineadmin. I move /home/wineadmin/.wine-Diablo_II and a create a new empty directory ~/.wine-Diablo_II and .wine-Diablo_II_rw. I mount the /srv/wine/.wine-Diablo_II the same as I did for administrator. I then install the Median XL mpq file. I then unmount .wine-Diablo_II and copy the contents of .wine-Diablo_II_rw (excluding .wh.*) to /srv/wine/.wine-Diablo_II_Median_XL. In the administrator home, I create two new directories, .wine-Diablo_II_Median_XL and .wine-Diablo_II_Median_XL_rw then mount them with aufs: mount -v -t aufs -o br:/home/administrator/.wine-Diablo_II_Median_XL_rw=rw:/srv/wine/.wine-Diablo_II=ro:/srv/wine/.wine-Diablo_II_Median_XL=ro none /home/administrator/.wine-Diablo_II_Median_XL I then fix the registry, links, and menu entries. The user now has two different Diablo II installations, original and Median XL. They act completely independent of each other which is important because game save files from Median XL are not compatible with the original game. Total size for one user is 2.3GB and very little additional space for five users (or many more). For a single-file modification this may seem overcomplicated but modifications in other games have hundreds of files that are changed including changes in the Wine registry. With registry changes I normally create a diff of them and patch it back in for each user. I have shell scripts that perform some of the work. When the users update the game or add
Re: UID/GID support
Jeff Hanson: Users can't run chown because they are not root. How about writing a wrapper? Allow chown after some tests. - the target path is aufs, or /home/$USER in your case? - the target uid is $USER - etc The warpper may be implemented suid-ed, or customized /etc/sudoers. -- Another problem is that the CIFS mounts show up in Gnome/Nautilus as mounted volumes. Since these are ro mounts that only exist for the UID change they aren't useful to the user and just make a mess of the desktop and Nautilus places sidebar. The aufs mount point is what the user needs. You may want to try fuse, nfs or any other fs which has uid-mapping feature. After some considerations, I could understand why you want such feature in aufs. But as I wrote first, I don't think it is a feature of stackable filesystem. Aufs should follow and should not disturb the native behaviour of brach fs. J. R. Okajima -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb
Re: UID/GID support
Hello Jeff, Jeff Hanson: point. From reading through the man page and the following posting, it appears that AUFS doesn't support setting the mount point UID/GID independently of the branches: https://sourceforge.net/mailarchive/message.php?msg_id=21772475 Is there any plan to add UID/GID setting in the future? Currently I have to run everything through CIFS which supports UID/GID setting. This adds a lot of work as I need a CIFS mount for every user * every Wine application directory. While I think it may be possible to implement such feature in aure, aufs should not do it. Because it is a different kind of feature. I think it is better to wrap the ro branch by fuse or cifs as you are doing. If I were you, I'd suggest user to run chown before you modify files. J. R. Okajima -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb
Re: UID/GID support
On Fri, Feb 4, 2011 at 8:56 AM, sf...@users.sourceforge.net wrote: While I think it may be possible to implement such feature in aure, aufs should not do it. Because it is a different kind of feature. I think it is better to wrap the ro branch by fuse or cifs as you are doing. If I were you, I'd suggest user to run chown before you modify files. Users can't run chown because they are not root. -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb
