VirtualBox

Ticket #1260 (reopened defect)

Opened 6 years ago

Last modified 12 months ago

VirtualBox disrespects umask when creating files in shared folders => Fixed in SVN

Reported by: mondalaci Owned by:
Priority: minor Component: shared folders
Version: VirtualBox 1.5.6 Keywords: umask permission problem
Cc: Guest type: other
Host type: Linux

Description (last modified by frank) (diff)

I want my WinXP guest to create files using shared folders on the filesystem of my Gutsy host with the permission 644. I set umask to 0022, but VirtualBox creates files with permission 600.

I've even modified the VirtualBox script right before

exec "/usr/lib/virtualbox/VirtualBox" "$@"

to include

umask 0022

but VirtualBox obviously disrespects umask by creating files with permission 600.

Attachments

vbox-umask.patch Download (826 bytes) - added by schuetzm 5 years ago.

Change History

comment:1 Changed 6 years ago by frank

  • Host type changed from other to Linux

comment:2 Changed 6 years ago by frank

  • Component changed from other to shared folders

comment:3 Changed 5 years ago by altmind

I acknowledge this bug and propose it being fixed.

Is there a quickfix?

comment:4 Changed 5 years ago by ds

I acknowledge this bug also and propose it being fixed.

Is there a workaround?

comment:5 Changed 5 years ago by ds

btw: I am using VirtualBox 2.1.2r41885

comment:6 Changed 5 years ago by ds

More info: When creating directories, the permissions are bein correctly created.

comment:7 Changed 5 years ago by pt

omg i am retarded

comment:8 Changed 5 years ago by meiser

I would also be interested in a solution.

Changed 5 years ago by schuetzm

comment:9 Changed 5 years ago by schuetzm

The problem is that VirtualBox specifies a mode of 0600 when creating a file. This can be trivially fixed by using 0666 instead, which would then automatically be combined with the umask to yield 0644 (see the attached patch vbox-umask.patch).

However, I do not know the reason why 0600 has been used there in the first place.

comment:10 in reply to: ↑ description Changed 5 years ago by kynx

This is a big one for me (OSX host, Linux guest). If I mount a group-writable directory, when users in that group create files they can't even read them!

I can understand it if the guest OS doesn't support the concept of a umask - perhaps then the solution would be to add a 'cmode' option to the mount command? But if OS does support umask wouldn't it make sense to honour it?

comment:11 Changed 5 years ago by meiser

Issue is also present in 2.2.0 beta2.

comment:12 Changed 5 years ago by frank

  • Summary changed from VirtualBox disrespects umask when creating files in shared folders to VirtualBox disrespects umask when creating files in shared folders => Fixed in SVN

A simple fix will be contained in the upcoming release. The file permissions will be 0222 if the guest opened the file write-only, 0444 if the guest opened the file read-only and 0666 if the guest opened the file with read/write permissions.

comment:13 Changed 5 years ago by meiser

works perfectly in 2.2.0. From my POV, this ticket can be closed.

comment:14 Changed 5 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed

comment:15 Changed 5 years ago by meiser

  • Status changed from closed to reopened
  • Resolution fixed deleted

Issue is there again with 3.0.0.

comment:16 Changed 5 years ago by umoeller

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed in 3.0.2.

comment:17 Changed 4 years ago by pepijnve

  • Status changed from closed to reopened
  • Resolution fixed deleted

I'm getting this behavior again in 3.1.6. getfacl output of all existing directories is

# file: Snapshots/
# owner: root
# group: vboxusers
# flags: -s-
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

However, newly created files get rw-------.

comment:18 Changed 4 years ago by meiser

Same for me with 3.1.6, although all files have permission 666 instead of 644 (as my umask is 0022).

comment:19 Changed 4 years ago by schuetzm

I can confirm this regression with 3.2.4. Btw, the permissions are correct when the file is created via Right Click -> New -> ... in Windows Explorer; but in Office (2007 here) it sets 666 instead of 644.

comment:20 Changed 4 years ago by frank

To be sure: Which was the last working VBox release for you?

comment:21 Changed 4 years ago by schuetzm

For me it was 3.1.4, but I did not test anything in between that version and the current one.

comment:22 Changed 4 years ago by frank

Works fine here when creating a file manually or saving a page from the internet explorer. Linux host, WinXP guest. Do you have some simpler test? Don't have Office available here...

comment:23 Changed 4 years ago by schuetzm

This bug is still there in version 3.2.6.

comment:24 Changed 4 years ago by frank

Well, if you don't answer my question I cannot help you.

comment:25 Changed 4 years ago by schuetzm

No, I don't have a simpler test. But as you don't have office, I guess you still cannot help me.

comment:26 Changed 3 years ago by schuetzm

This bug is still present in 4.0.8.

comment:27 Changed 22 months ago by garsax

This bug is still present in 4.1.18 and there's a similar ticket  #10534

I wonder how such an important and basic issue keeps unsolved after 4 years!

comment:28 Changed 22 months ago by frank

  • Description modified (diff)

This bug has nothing to do with #10534. And if you would take some time and actually read the above comments then you would observe that there is no simple test case to reproduce the problem of this ticket.

comment:29 Changed 22 months ago by garsax

Ok, from the begining:

  • Host is Linux, guest is Windows.
  • Host shares a folder with permissions: xrwxrwxrw (full access everyone)
  • Guest accesses the shared folder like \\vboxsvr\shared and creates a brand new file there.
  • From the Linux host this new file has permissions: -rw-r--r-- (only the owner can write).
  • No matter how umask is set in the Linux host.

If this is not the ticket for this example I apologize and I would ask you to point me in the right direction.

comment:30 Changed 22 months ago by frank

That's a better description and this sounds more like this ticket. Have to reproduce this.

comment:31 Changed 22 months ago by frank

Cannot reproduce this. This is what I did on a Linux host:

  1. On the host, do umask 0.
  2. On the host, start a Linux guest.
  3. In the guest, do cd /shared_folder and touch foo
  4. On the host, the file foo has -rw-r--r--.
  5. In the guest, do umask 0 and touch bar
  6. On the host, the file bar has -rw-rw-rw-
  7. On the host, start a Windows XP guest.
  8. In the guest, do echo 123 > buzz in a cmd.exe window
  9. On the host, buzz has -rw-rw-rw-

I used VBox 4.1.18 with Guest Additions 4.1.18. Keep in mind that the guest umask is also respected, i.e. if the guest creates a file with umask 022 then the file on the host cannot have the 'w' bit set for group and others.

So what does not work for you?

comment:32 Changed 22 months ago by garsax

This are the detailed steps:

  • On Linux host:
$ umask
0002
$ echo host > /shared/host.txt
$ ls -l /shared/*.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt
  • Start a Windows guest and open a cmd.exe box:
echo guest > \\vboxsvr\shared\guest1.txt
echo guest > \\sol\shared\guest2.txt
  • From the Linux host again:
$ ls -l /shared/*.txt
-rw-r--r-- 1 jordi sambausers 8 Jun 28 15:54 /shared/guest1.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/guest2.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt

Notes:

  • umask is 0002 and it works as expected on Linux.
  • \\vboxsvr\shared and \\sol\shared are excatly the same place (the later is shared by samba).
  • The final results show us that accessing via \\vboxsvr sets permissions as -rw-r--r-- and any other user from the same group can't edit the file.
  • I need to access via \\vboxsvr as the samba share may not be avaliable all time (due to VPN restrictions on the Windows guest).
  • I'm using VBox 4.1.18 with Guest Additions 4.1.18.
Last edited 22 months ago by garsax (previous) (diff)

comment:33 Changed 22 months ago by garsax

Wait, that's funny:

  • On the same Windows guest, on the cmd.exe box:
attrib -a \\vboxsvr\shared\guest1.txt
  • and back to the Linux host again:
$ ls -l /shared/*.txt
-rw-rw-rw- 1 jordi sambausers 8 Jun 28 15:54 /shared/guest1.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/guest2.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt

Now permissions are -rw-rw-rw- ...I don't get it...

May be a workaround? May be a security issue too?

comment:34 Changed 21 months ago by garsax

Time goes by and there is no news about this annoying bug :(

It is supposed to be fixed in the past but somehow the patch attached to this ticket is NOT applied in VirtualBox 4.1.x series (I've downloaded the source files for VirtualBox 4.1.18 and witnessed that the old wrong code is actually there).

So far the only working workaround I've found is to schedule cron to reset the file permissions on the Linux host. Something like:

*/5 * * * * chmod -R 777 /Shared

(this should reset permissions on /Shared and subfolders every 5 min. Not nice, I know)

So, there's a problem. We've detected it. We've reported it. We've got a patch to solve it... and this ticket remains open (re-open) for so long!

Please, just apply the patch to your next release!

Guys from VirtualBox/Oracle, how can we get this fixed???

comment:35 Changed 21 months ago by frank

The patch is wrong as it changes the umask to every file which is created by VirtualBox on the host. And no, we cannot rely on the user setting the umask variable correct. Oracle has a policy to not grant more permissions to a file than necessary.

We will try to reproduce your scenario when we find some time, other issues are waiting for a fix as well.

comment:36 Changed 21 months ago by garsax

First of all, thank you for your answer and your effort. I'm sure there're many other things to attend to and I appreciate your feedback on this ticket.

On the other hand, respectfully and in my humble opinion, this issue remains open for too long now (4 years?) to just let it go with a "when we find some time for it". Is it possible to know a more specific time frame?

Finally, I agree the patch it's not the perfect solution. The perfect solution would be VirtualBox to respect the system umask. But since in VirtualBox one can choose which folders will be shared (security issues can be contained), I prefer to allow access to everyone (as the patch do) than not having the option to share any file with other users.

Once again, thank you for your support.

comment:37 Changed 18 months ago by gregthegeek

Just wanted to chime in on this issue. I think I am seeing similar. Windows XP guest, guest additions installed, mapped to
vboxsvr\share. LInux host (Ubuntu 12.04) shows files created as root and 0644 when umask is 0002. I need group ownership to be rw in this system. As a workaround I will probably just map to samba, but I like the idea of using the Vbox share better and skipping that whole smb thing.

comment:38 Changed 14 months ago by dr2chase

4.2.6, I see the problem running Virtual Solaris on top of MacOS.

Would it be too hard, if you cannot by default trust a Unix user to use Unix as Unix was intended to behave, to add an option that could be changed by people who need Unix to be actually be Unix? This is a show-stopper for me -- if I have to copy the files anyway to get the permissions I need, I might as well use a Real Box instead. The development tools I use don't work with this broken file system.

In case you still need assistance in reproducing this problem, here:

xxx:/mnt/sf_mywork/jdk8tl$ cat > foo
foo
xxx:/mnt/sf_mywork/jdk8tl$ ls -l foo
-rw-r--r--   1 root     vboxsf         4 Feb 23 12:11 foo
xxx:/mnt/sf_mywork/jdk8tl$ umask
0000
Version 0, edited 14 months ago by dr2chase (next)

comment:39 Changed 14 months ago by dr2chase

PS, on the security front, I think you guys are missing the forest for the trees. Look at the workaround people are using -- as a very first step, they are doing "chmod -R go+w ." on the entire shared directory. One guy up there has a cron job doing this. Your "enhanced security" is inducing user behavior that is far less secure than anything they would do by accident using VirtualBox.

The feature I think I'm after and that sounds like it would cause fewer problems for people like me is an option to map a subset of the host users directly into the virtual box OS, and to mirror shared files straight through. Not sure how hard this would be, but it's what I want, and I would no longer need to do wholesale permission changes in shared directories just so I could use them properly in VirtualBox. This has a minor incompatibility with what appears to be the current rule of mapping the VirtualBox process owner to root in the VM.

comment:40 Changed 12 months ago by JWrong

Remedy for this problem which worked for me is to set proper permissions and umask when mounting the shared folder.

Example:

mount -t vboxsf -o uid=1000,gid=1000,dmode=777,fmode=666 sharedfolder /var/www/website


uid and gid are the ids of the user and group which will have ownership of the shared folder (in my case I've set these to be id and group of my apache2 process: www-data)
dmode and fmode are respectively new directory and new file permissions (decimal).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use