1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/118/network/1299 b/results/classifier/118/network/1299
new file mode 100644
index 00000000..456ccc56
--- /dev/null
+++ b/results/classifier/118/network/1299
@@ -0,0 +1,54 @@
+network: 0.973
+user-level: 0.937
+virtual: 0.894
+graphic: 0.862
+device: 0.852
+files: 0.817
+semantic: 0.816
+architecture: 0.813
+performance: 0.810
+permissions: 0.742
+register: 0.711
+ppc: 0.673
+vnc: 0.619
+socket: 0.614
+debug: 0.569
+PID: 0.553
+mistranslation: 0.539
+risc-v: 0.491
+boot: 0.489
+arm: 0.461
+peripherals: 0.454
+hypervisor: 0.445
+KVM: 0.356
+kernel: 0.332
+i386: 0.330
+TCG: 0.315
+VMM: 0.297
+assembly: 0.247
+x86: 0.243
+
+User networking with an SMB Share while not running as root
+Description of problem:
+When attempting to write a file to the qemu share, Samba always responds with NT_STATUS_ACCESS_DENIED.
+
+This only happens on the MacOS version of Samba, on Linux it appears to work without issues for now.
+Steps to reproduce:
+1. Start a VM with a SMB share attached to it
+2. Create a test file to upload `touch test-file.txt`
+3. Upload the test file `smbclient //10.0.2.4/qemu -c 'put test-file.txt'
+Additional information:
+QEMU has been using Samba for it's SMB shares for quite some time now.
+But in the 4.17.x release a bug has appeared in the MacOS Build of Samba.
+
+I've filed a bug with Samba, and suggested a fix for it.
+https://bugzilla.samba.org/show_bug.cgi?id=15215
+
+The origin of the bug lies in the fact that when running SMBD as a non-root user, a function sets `errno` unexpectedly.
+But after discussing this with Samba, they concluded that running smbd as an un-privileged user is not a supported use case.
+
+Whilst this is not a QEMU bug per se, it is caused by the fact that QEMU is running smbd in an unsupported manner.
+
+As a side note, on Linux this bug does not appear to exist as of yet.
+The Linux version of `unbecome_root` doesn't seem to set `errno`. (tested on a recent ArchLinux install).
+But I think this depends on the LibC implementation of setuid/seteuid/setreuid/etc. so I can't say it won't happen in the future, or with a different LibC implementation.