blob: 456ccc5651afcbe0f2c96acf13115ba0c93735a5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
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.
|