staging.inyokaproject.org

Hallo zusammen,

mich plagt ein Problem mit einem Samba share in meinem Lab. Weder ich, noch mein Dozent weiß weiter...aber erst mal zur Situation.

OS Server: Ubuntu Server 1604 Kernel 4.4.x , auch Ubuntu 1610 Desktop,CentOS7 oder Kali haben das gleiche Problem OS Client: Ubuntu 1610 Desktop, CentOS7 und Windows 10 Pro

Problem: Sobald ich ein Ordner freigebe -mittels smb.conf- und darin eine simple Datei als root anlege, kann ein User die via der GUI (vfs?) editieren, abspeichern und den Besitz übernehmen. Ist der Zugriff via einem Mount und der BASH, werden alle Dateirechte forciert und alles arbeitet wie gewohnt.

Was hab ich getan: Im Pfad /srv/ ein Ordner "testshare" mit Rechten 777 angelegt. In der smb.conf folgende Einträge vorgenommen

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

[global]
	workgroup = SPE
	netbios name = SPE
	server string = %h server (Samba, Ubuntu)
	server role = standalone server
	security = USER
	map to guest = Bad User
	obey pam restrictions = Yes
	pam password change = Yes
	passwd program = /usr/bin/passwd %u
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	unix password sync = Yes
	syslog = 0
	log file = /var/log/samba/log.%m
	max log size = 1000
	dns proxy = No
	panic action = /usr/share/samba/panic-action %d
	idmap config * : backend = tdb


[testshare]
	comment = Test-Freigabe (Zugriff von %u%I)
	path = /srv/testshare
	read only = No

Danach ein testparm einen kurzen Check und mit smbpasswd -a userxy einen Testnutzer angelegt.

Soweit so gut. Als root, sind ein paar Dateien mit etwas lorem ipsum mittels touch in den share erstellt worden. Alle root Dateien haben xrw xrw r also 774 als Dateirechte gesetzt. Greife ich nun mit einem Client auf den share zu, -nach erfolgreicher Authentifizierung- kann ich als normaler user die Datei vom root lesen (logisch) und editieren (wtf?)...danach wechselt der Eigentümer von root auf den Namen des users um....das obwohl der user max lesen hat?

Entziehe ich einer root datei die others:read Berechtigung –> 770, dann kann der remote user die Datei nicht mehr öffnen (logisch), sobald wieder das read flag gesetzt wurde, hab ich obiges Problem. Wie bereits geschrieben, diese Problematik ist nur bei einem Zugriff über Nautilus und co! nicht via BASH.

Interessant finde ich, das ein remote Zugriff von Windows 10 auf den Samba share die Dateirechte allerdings berücksichtigt, sprich, root Dateien sind nicht editierbar.

Natürlich hab ich die MAN Pages, Server Handbuch und RedHat Doku gelesen...doch offensichtlich hab ich etwas grundlegendes übersehen. Die gleiche Config mit einem 5 Jahre alten Suse Linux hat nicht diese Probleme...sprich, da muss sich während den Versionssprüngen etwas getan haben.

Es tut mir Leid, aber stellenweise sollte ich präzisere Angaben haben.

Sobald ich ein Ordner freigebe -mittels smb.conf- und darin eine simple Datei als root anlege

Auf dem Server direkt oder über das Netz mittels Samba? Wie sind die Rechte auf dem Server festgelegt? Zu ermitteln über ls -la <Freigabe>.

...kann ein User die via der GUI (vfs?) editieren, abspeichern und den Besitz übernehmen.

Du meinst wohl "über den Dateimanager darauf zugreifen usw." Das geschieht dann über das GVFS, und dabei werden die UNIX-Extensions nicht verwendet. Dies bedeutet, dass die Dateirechte vom Server nicht auf den Client übernommen werden.

Ist der Zugriff via einem Mount und der BASH, werden alle Dateirechte forciert und alles arbeitet wie gewohnt.

Da wird eben nicht das GVFS, sondern das cifs-vfs verwendet, und dieses verwendet standardmäßig die UNIX-Extensions.

danach wechselt der Eigentümer von root auf den Namen des users um....das obwohl der user max lesen hat?

Ich verstehe leider nicht, was das heißen soll.

Weiterhin von Interesse könnten noch die Ausgaben nach folgenden Befehlszeilen auf dem Server sein (bitte als Codeblock posten):

testparm -v | grep admin
getfacl <Freigabe> 

Gruß – Max-Ulrich

Auf dem Server direkt oder über das Netz mittels Samba? Wie sind die Rechte auf dem Server festgelegt? Zu ermitteln über ls -la <Freigabe>.

...kann ein User die via der GUI (vfs?) editieren, abspeichern und den Besitz übernehmen.

Wie bereits geschrieben, der Test-Ordner hat eine 777 Berechtigung, sprich das list cmd zeig t rwxrwxrwx. Ich möchte ja, das JEDER in diesem Ordner etwas ablegen kann, root Dateien ansich, dürfen nur maximal rwxrwxr sein, sprich, andere non root Nutzer dürfen nur die Datei lesen, mehr nicht.

Du meinst wohl "über den Dateimanager darauf zugreifen usw." Das geschieht dann über das GVFS, und dabei werden die UNIX-Extensions nicht verwendet. Dies bedeutet, dass die Dateirechte vom Server nicht auf den Client übernommen werden.

Ist der Zugriff via einem Mount und der BASH, werden alle Dateirechte forciert und alles arbeitet wie gewohnt.

Genau, da bin ich aktuell völlig ratlos, wie ich die Extensions dennoch verteile. Anscheinend ist das GVFS System noch gar nicht mal sooo alt. Hier nutzen wir u.a. eine 5 Jahre alte SuSE Distro, dort sind alle Dateirachte 1:1 übernommen, wenn man mittels einen grafischen Dateimanager auf einen Share zugreift.

danach wechselt der Eigentümer von root auf den Namen des users um....das obwohl der user max lesen hat?

Ich verstehe leider nicht, was das heißen soll.

Ein Ordner, welchen ich ganz klassisch via Samba freigebe...nicht mittels des Dateimanagers, sondern mit Einträgen in der smb.conf. Sobald in diesem Ordner eine Datei mit dem Eigentümer root hinterlegt ist (rwx rwx r) und daraufhin ein User über das LAN einen Zugriff startet mittels Dateimanager, so kann der User diese Datei nicht nur lesen, sondern auch editieren. Kontrolliert man nun wieder auf dem Server die Rechte mittels einem ll (oder sonstiger ls Kombination), ist der Eigentümer nicht mehr root, sondern der User!

Sobald das read flag einer root Datei weg ist, kann der user nicht mehr darauf zugreifen. Ein gesetztes read flag reicht jedoch aus, hier vollen Zugriff zu ermöglichen.

  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
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446

# Global parameters
[global]
	dos charset = CP850
	unix charset = UTF-8
	workgroup = SPE
	realm = 
	netbios name = SPE
	netbios aliases = 
	netbios scope = 
	server string = %h server (Samba, Ubuntu)
	interfaces = 
	bind interfaces only = No
	config backend = file
	server role = standalone server
	security = USER
	auth methods = 
	encrypt passwords = Yes
	client schannel = Auto
	server schannel = Auto
	allow trusted domains = Yes
	map to guest = Bad User
	null passwords = No
	old password allowed period = 60
	obey pam restrictions = Yes
	password server = *
	smb passwd file = /etc/samba/smbpasswd
	private dir = /var/lib/samba/private
	passdb backend = tdbsam
	algorithmic rid base = 1000
	root directory = 
	guest account = nobody
	enable privileges = Yes
	pam password change = Yes
	passwd program = /usr/bin/passwd %u
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	passwd chat debug = No
	passwd chat timeout = 2
	check password script = 
	username map = 
	username level = 0
	unix password sync = Yes
	restrict anonymous = 0
	lanman auth = No
	ntlm auth = Yes
	raw NTLMv2 auth = No
	client NTLMv2 auth = Yes
	client lanman auth = No
	client plaintext auth = No
	client use spnego principal = No
	preload modules = 
	dedicated keytab file = 
	kerberos method = default
	map untrusted to domain = No
	log level = 2
	syslog = 0
	syslog only = No
	log file = /var/log/samba/log.%m
	logging = 
	max log size = 1000
	debug timestamp = Yes
	timestamp logs = Yes
	debug prefix timestamp = No
	debug hires timestamp = Yes
	debug pid = No
	debug uid = No
	debug class = No
	enable core files = Yes
	smb ports = 445 139
	large readwrite = Yes
	server max protocol = SMB3
	max protocol = SMB3
	protocol = SMB3
	server min protocol = LANMAN1
	min protocol = LANMAN1
	client max protocol = default
	client min protocol = CORE
	unicode = Yes
	min receivefile size = 0
	read raw = Yes
	write raw = Yes
	disable netbios = No
	reset on zero vc = No
	log writeable files on exit = No
	defer sharing violations = Yes
	nt pipe support = Yes
	nt status support = Yes
	smbd profiling level = off
	max mux = 50
	max xmit = 16644
	name resolve order = lmhosts wins host bcast
	max ttl = 259200
	max wins ttl = 518400
	min wins ttl = 21600
	time server = No
	unix extensions = Yes
	use spnego = Yes
	client signing = default
	server signing = default
	client use spnego = Yes
	client ldap sasl wrapping = sign
	ldap server require strong auth = Yes
	enable asu support = No
	svcctl list = 
	cldap port = 389
	dgram port = 138
	nbt port = 137
	krb5 port = 88
	kpasswd port = 464
	web port = 901
	rpc big endian = No
	deadtime = 0
	getwd cache = Yes
	keepalive = 300
	change notify = Yes
	kernel change notify = Yes
	lpq cache time = 30
	max smbd processes = 0
	max disk size = 0
	max open files = 16384
	socket options = TCP_NODELAY
	use mmap = Yes
	hostname lookups = No
	name cache timeout = 660
	ctdbd socket = 
	cluster addresses = 
	clustering = No
	ctdb timeout = 0
	ctdb locktime warn threshold = 0
	smb2 max read = 8388608
	smb2 max write = 8388608
	smb2 max trans = 8388608
	smb2 max credits = 8192
	load printers = Yes
	printcap cache time = 750
	printcap name = 
	cups server = 
	cups encrypt = No
	cups connection timeout = 30
	iprint server = 
	disable spoolss = No
	addport command = 
	enumports command = 
	addprinter command = 
	deleteprinter command = 
	show add printer wizard = Yes
	os2 driver map = 
	mangling method = hash2
	mangle prefix = 1
	max stat cache size = 256
	stat cache = Yes
	machine password timeout = 604800
	add user script = 
	rename user script = 
	delete user script = 
	add group script = 
	delete group script = 
	add user to group script = 
	delete user from group script = 
	set primary group script = 
	add machine script = 
	shutdown script = 
	abort shutdown script = 
	username map script = 
	username map cache time = 0
	logon script = 
	logon path = \\%N\%U\profile
	logon drive = 
	logon home = \\%N\%U
	domain logons = No
	init logon delayed hosts = 
	init logon delay = 100
	os level = 20
	lm announce = Auto
	lm interval = 60
	preferred master = Auto
	local master = Yes
	domain master = Auto
	browse list = Yes
	enhanced browsing = Yes
	dns proxy = No
	wins proxy = No
	wins server = 
	wins support = No
	wins hook = 
	smb2 leases = No
	lock spin time = 200
	oplock break wait time = 0
	'''[mark]ldap admin dn =[/mark]''' 
	ldap delete dn = No
	ldap group suffix = 
	ldap idmap suffix = 
	ldap machine suffix = 
	ldap passwd sync = no
	ldap replication sleep = 1000
	ldap suffix = 
	ldap ssl = start tls
	ldap ssl ads = No
	ldap deref = auto
	ldap follow referral = Auto
	ldap timeout = 15
	ldap connection timeout = 2
	ldap page size = 1024
	ldap user suffix = 
	ldap debug level = 0
	ldap debug threshold = 10
	eventlog list = 
	add share command = 
	change share command = 
	delete share command = 
	config file = 
	preload = 
	auto services = 
	lock directory = /var/run/samba
	state directory = /var/lib/samba
	cache directory = /var/cache/samba
	pid directory = /var/run/samba
	ntp signd socket directory = /var/lib/samba/ntp_signd
	utmp directory = 
	wtmp directory = 
	utmp = No
	default service = 
	default = 
	message command = 
	get quota command = 
	set quota command = 
	remote announce = 
	remote browse sync = 
	nbt client socket address = 0.0.0.0
	socket address = 0.0.0.0
	nmbd bind explicit broadcast = Yes
	homedir map = auto.home
	afs username map = 
	afs token lifetime = 604800
	log nt token command = 
	NIS homedir = No
	registry shares = No
	usershare allow guests = No
	usershare max shares = 100
	usershare owner only = Yes
	usershare path = /var/lib/samba/usershares
	usershare prefix allow list = 
	usershare prefix deny list = 
	usershare template share = 
	allow insecure wide links = No
	async smb echo handler = No
	panic action = /usr/share/samba/panic-action %d
	perfcount module = 
	host msdfs = Yes
	passdb expand explicit = No
	idmap backend = tdb
	idmap cache time = 604800
	idmap negative cache time = 120
	idmap uid = 
	idmap gid = 
	template homedir = /home/%D/%U
	template shell = /bin/false
	winbind separator = \
	winbind cache time = 300
	winbind reconnect delay = 30
	winbind request timeout = 60
	winbind max clients = 200
	winbind enum users = No
	winbind enum groups = No
	winbind use default domain = No
	winbind trusted domains only = No
	winbind nested groups = Yes
	winbind expand groups = 0
	winbind nss info = template
	winbind refresh tickets = No
	winbind offline logon = No
	winbind normalize names = No
	winbind rpc only = No
	create krb5 conf = Yes
	ncalrpc dir = /var/run/samba/ncalrpc
	winbind max domain connections = 1
	winbindd socket directory = /var/run/samba/winbindd
	winbindd privileged socket directory = /var/lib/samba/winbindd_privileged
	winbind sealed pipes = Yes
	neutralize nt4 emulation = No
	reject md5 servers = No
	require strong key = Yes
	allow dns updates = secure only
	dns forwarder = 
	dns update command = /usr/sbin/samba_dnsupdate
	nsupdate command = /usr/bin/nsupdate -g
	rndc command = /usr/sbin/rndc
	multicast dns register = Yes
	samba kcc command = /usr/sbin/samba_kcc
	server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, dns
	dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver
	spn update command = /usr/sbin/samba_spnupdate
	share backend = classic
	allow nt4 crypto = No
	reject md5 clients = No
	tls enabled = Yes
	tls keyfile = tls/key.pem
	tls certfile = tls/cert.pem
	tls cafile = tls/ca.pem
	tls crlfile = 
	tls dh params file = 
	tls priority = NORMAL:-VERS-SSL3.0
	tls verify peer = as_strict_as_possible
	client ipc max protocol = default
	client ipc min protocol = default
	client ipc signing = default
	allow dcerpc auth level connect = No
	idmap config * : backend = tdb
	comment = 
	path = 
	username = 
	invalid users = 
	valid users = 
	[mark]'''admin users = '''[/mark]
	read list = 
	write list = 
	force user = 
	force group = 
	group = 
	read only = Yes
	spotlight = No
	acl check permissions = Yes
	acl group control = No
	acl map full control = Yes
	acl allow execute always = No
	create mask = 0744
	force create mode = 0000
	directory mask = 0755
	directory mode = 0755
	force directory mode = 0000
	force unknown acl user = No
	inherit permissions = No
	inherit acls = No
	inherit owner = No
	guest only = No
	'''[mark]administrative share = No[/mark]'''
	guest ok = No
	only user = No
	hosts allow = 
	hosts deny = 
	allocation roundup size = 1048576
	aio read size = 0
	aio write size = 0
	aio write behind = 
	ea support = No
	nt acl support = Yes
	profile acls = No
	map acl inherit = No
	afs share = No
	smb encrypt = default
	durable handles = Yes
	block size = 1024
	directory name cache size = 100
	max connections = 0
	min print space = 0
	strict allocate = No
	strict rename = No
	strict sync = No
	sync always = No
	use sendfile = No
	write cache size = 0
	max reported print jobs = 0
	max print jobs = 1000
	printable = No
	print notify backchannel = No
	printing = cups
	cups options = 
	print command = 
	lpq command = %p
	lprm command = 
	lppause command = 
	lpresume command = 
	queuepause command = 
	queueresume command = 
	printer name = 
	use client driver = No
	default devmode = Yes
	force printername = No
	printjob username = %U
	default case = lower
	case sensitive = Auto
	preserve case = Yes
	short preserve case = Yes
	mangling char = ~
	hide dot files = Yes
	hide special files = No
	hide unreadable = No
	hide unwriteable files = No
	delete veto files = No
	veto files = 
	hide files = 
	veto oplock files = 
	map archive = Yes
	map hidden = No
	map system = No
	map readonly = yes
	mangled names = Yes
	store dos attributes = No
	dmapi support = No
	browseable = Yes
	access based share enum = No
	blocking locks = Yes
	csc policy = manual
	fake oplocks = No
	kernel oplocks = No
	kernel share modes = Yes
	locking = Yes
	oplocks = Yes
	level2 oplocks = Yes
	oplock contention limit = 2
	posix locking = Yes
	strict locking = Auto
	dfree cache time = 0
	dfree command = 
	include = 
	preexec = 
	exec = 
	preexec close = No
	postexec = 
	root preexec = 
	root preexec close = No
	root postexec = 
	available = Yes
	volume = 
	fstype = NTFS
	wide links = No
	follow symlinks = Yes
	dont descend = 
	magic script = 
	magic output = 
	delete readonly = No
	dos filemode = No
	dos filetimes = Yes
	dos filetime resolution = No
	fake directory create times = No
	vfs objects = 
	msdfs root = No
	msdfs proxy = 
	msdfs shuffle referrals = No
	ntvfs handler = unixuid, default


[testshare]
	comment = Test-Freigabe (Zugriff von %u%I)
	path = /srv/testshare
	read only = No
	inherit acls = Yes

Die getfacl Ausgabe

1
2
3
4
5
6

# file: srv/testshare/
# owner: root
# group: root
user::rwx
group::rwx
other::rwx

Rekursiv auf die Dateien im Test Ordner angewandt, zeigt getfacl deutlich, das keine gvfs offensichtlich hier ein Sicherheitsrisiko darstellt?!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# file: srv/testshare//demo.txt //wurde als root angelegt
# owner: userxy                 //Datei geöffnet, beschrieben und Eigentümer wurde userxy. Zugriff via Dateimanager
# group: userxy
user::rwx
group::rwx
other::r--

# file: srv/testshare//meagain.txt
# owner: root
# group: root
user::rwx
group::rwx
other::r--

Gibt es einen Weg, die Unix Extensions zu erzwingen???

Gibt es einen Weg, die Unix Extensions zu erzwingen???

Ja, man mountet die entsprechenden Freigaben statisch z.B. durch einen Eintrag in fstab. Man kann diesen Eintrag auch mit der Option noauto versehen, dann wird das Mounten nur vorbereitet und kann dann jederzeit von Hand oder automatisch über den Automounter von systemd vorgenommen werden. Man muss halt auf jeden Fall das GVFS vermeiden, da dieses die Extensions prinzipiell nicht unterstützen kann (bzw. nicht will, denn es ist bei Samba absichtlich weitgehend an das Verhalten eines Windows-Client angepasst).

Anscheinend ist das GVFS System noch gar nicht mal sooo alt. Hier nutzen wir u.a. eine 5 Jahre alte SuSE Distro

In den Jahren 2008-2009 wurde das vorherige GnomeVFS, das anders funktioniert hatte, sukzessive in allen GTK-basierten Oberflächen durch das damals neue GVFS ersetzt. In den qt-basierten Oberflächen, also KDE, gibt es kein GVFS, sondern KIO-Slaves. Was für eine Oberfläche SUSE verwendet bzw. vor 5 Jahren verwendet hat, weiß ich nicht. Doch es könnte sehr wohl KDE sein.

…daraufhin ein User über das LAN einen Zugriff startet mittels Dateimanager, so kann der User diese Datei nicht nur lesen, sondern auch editieren. Kontrolliert man nun wieder auf dem Server die Rechte mittels einem ll (oder sonstiger ls Kombination), ist der Eigentümer nicht mehr root, sondern der User!

Dieses Verhalten wundert mich sehr. Ich muss 'mal sehen, ob ich es nachvollziehen kann (??). Ich kann mir nicht vorstellen, wie ein Zugriff mittels GVFS von einem Linux-Client aus auf dem Server den Eigentümer einer bereits existierenden Datei verändern könnte. Bei einer Datei, die übers Netz neu angelegt wird, ist das anders. Dass es sich nicht um widersprechende ACLs handeln kann, zeigt ja getfacl. Ein irgendwie versteckter admin user müsste sich ja bei testparm -v | grep admin zeigen.

Gruß – Max-Ulrich

Dieses Verhalten wundert mich sehr. Ich muss 'mal sehen, ob ich es nachvollziehen kann (??).

Mein Dozent hat -so behauptet er 😈 - 30 Jahre OS Erfahrung...und seine grauen Haare lassen sich nicht weg diskutieren...doch als ich im das demonstrierte und er selbst lange an mein System es versucht hat, kam er aus dem staunen nicht mehr raus.

Bei SuSE ist es KDE, CentOS7 nutzt Gnome. Greife ich auf den Share mit dem Windows 10 Explorer zu, so sind alle Linux Dateirechte vorhanden! Der Übeltäter ist das gvfs System.

Trotzdem muss es irgendwie zu ändern sein. Probier mal eine Freigabe mittels dem Dateimanager zu errichten (klick klick Methode)...der Assistent unter Nautilus gibt einem 2 Basis Optionen vor...der nun freigegebene Ordner ist nicht! in der smb.conf sichtbar. Folglich, muss da noch eine andere Konfigurationsdatei hinterlegt sein. Komisch finde ich, das weder im offiziellen Ubuntu Server Manual, der Manpage zu Samba oder der smb.conf, noch in der RedHat Dokumentation (sehr gut!) Infos hierzu beschrieben sind. Hab dann noch X Bücher zu Linux (deutsche und US Englische),...auch hier, keine Info.

Ja, man mountet die entsprechenden Freigaben statisch z.B. durch einen Eintrag in fstab. Man kann diesen Eintrag auch mit der Option noauto versehen, dann wird das Mounten nur vorbereitet und kann dann jederzeit von Hand oder automatisch über den Automounter von systemd vorgenommen werden. Man muss halt auf jeden Fall das GVFS vermeiden, da dieses die Extensions prinzipiell nicht unterstützen kann (bzw. nicht will, denn es ist bei Samba absichtlich weitgehend an das Verhalten eines Windows-Client angepasst).

Statisch geht auch nur bedingt. Zugriff via Bash –> geht, fstab geht auch. Sobald irgendwie der Dateimanager involviert ist, kommen die Probleme.

Probier mal eine Freigabe mittels dem Dateimanager zu errichten (klick klick Methode)...der Assistent unter Nautilus gibt einem 2 Basis Optionen vor...der nun freigegebene Ordner ist nicht! in der smb.conf sichtbar. Folglich, muss da noch eine andere Konfigurationsdatei hinterlegt sein.

Das ist nichts Neues, aber es erklärt Dein Problem nicht. Die GTK-Dateimanager (Nautilus, Caja & Co) verwenden das Tool net usershare um Samba-Freigaben zu erstellen, da dies mit diesem Tool ohne Root-Rechte geht. Im Artikel Samba Server GNOME ist dies beschrieben. Solche Freigaben werden dann nicht in smb.conf eingetragen, da ja ohne Root-Rechte nicht in diese Datei geschrieben werden darf. Sie sind in /var/lib/samba/usershares/ zu finden, und zwar mit jeweils einer eigenen Datei, auf die nur der jeweils erstellende Benutzer Zugriff hat. Man nennt dies "Persönliche Freigaben" im Gegensatz zu den in smb.conf eingetragenen "Allgemeinen Freigaben". Die Persönlichen Freigaben haben eigene ACLs (nicht zu verwechseln mit den POSIX-ACLs). Doch diese dürften eigentlich die UNIX-Dateirechte suf dem Server nicht verändern.

Komisch finde ich, das weder im offiziellen Ubuntu Server Manual, der Manpage zu Samba oder der smb.conf, noch in der RedHat Dokumentation (sehr gut!) Infos hierzu beschrieben sind. Hab dann noch X Bücher zu Linux (deutsche und US Englische),...auch hier, keine Info.

In unserem Wiki steht das! 😉

Ich werde mich 'mal hinter das Problem klemmen, sobald ich etwas Zeit habe.

EDIT:

Statisch geht auch nur bedingt. Zugriff via Bash –> geht, fstab geht auch. Sobald irgendwie der Dateimanager involviert ist, kommen die Probleme.

Es geht schon, auch mit dem Dateimanager. Nur kann der Dateimanager parallel zu den statisch gemounteten Freigaben außerdem auch über das GVFS zugreifen, und dies ist optisch leider nicht deutlich unterschieden. Man muss deshalb sehr aufpassen, worauf bzw. wie man gerade zugreift. Um dieser etwas verwirrenden Tatsache auszuweichen gibt es die Möglichkeit, die Freigaben grundsätzlich als Allgemeine Freigaben zu erstellen (kein Klick…Klick), und zwar so, dass nur der Administrator darauf zugreifen darf. Dieser mountet dann die Freigaben auf dem Client (z.B. über fstab) und legt dann dabei fest, wer auf die gemounteten Freigaben wie zugreifen darf. Damit ist für alle Benutzer außer dem Administrator der direkte Weg über das GVFS ausgeschlossen. Dieser Weg geht mit oder ohne UNIX-Extensions.

Das Problem hat mir keine Ruhe gelassen. Nun ja, es ist ja auch sehr überraschend und nicht gerade unwichtig!!

Ich konnte folgendes feststellen:

• Das seltsame Verhalten, das NetworkWarrior festgestellt hat, und das uns alle irritiert, konnte ich zu meinem eigenen Erstaunen auf Anhieb nachvollziehen! Mir war dies bisher noch nie aufgefallen.

• Bei weiteren Versuchen habe ich festgestellt, dass dieses Verhalten ausschließlich bei "Persönlichen Freigaben" (die also mit net usershare erstellt sind) und nur beim Zugriff über das GVFS auftritt (KDE habe ich keines, die KIO-Slaves kann ich nicht testen). Bei "Allgemeinen Freigaben" (in smb.conf eingetragen) werden die Dateirechte des Servers auch beim Zugriff über das GVFS respektiert und nicht verändert.

• Bei mittels cifs-vfs gemounteten Freigaben tritt das Verhalten nicht auf, egal, ob es sich um "Persönliche" oder un "Allgemeine Freigaben" handelt.

• Mit den "UNIX Extensions" hat dies wohl direkt nichts zu tun. Mittels cifs-vfs gemountete Freigaben verhalten sich völlig korrekt, egal ob die Extensions aktiv sind oder nicht. Dies gilt auch, wenn über den Dateimanager auf diese zugegriffen wird.

Ich habe eine teilweise, aber keineswegs befriedigende Erklärung für das Phänomen: Standardmäßig können "persönlich" nur Ordner und Dateien freigegeben werden, die Eigentum des freigebenden Benutzers sind. Wenn ein Ordner "persönlich" freigegeben ist, geht das GVFS offenbar stillschweigend davon aus, dass der Ordner und sein gesamter Inhalt Eigentum dieses Benutzers sind (??).

Mit der Option usershare owner only = no im Teil [global] der smb.conf kann man diese Einschränkung deaktivieren und die Freigabe beliebiger Dateien mittels net usershare erlauben. Es wäre interessant, ob das Verhalten dadurch beeinflusst würde bzw. wie sich das GVFS allgemein bei dieser Einstellung verhalten würde. Das mache ich jetzt aber nicht.

Ich glaube nicht, dass das von NetworkWarrior beobachtete, irritierende Verhalten des GVFS Absicht ist. Ich denke vielmehr, dass es sich hier wohl um einen Bug im GVFS oder in Samba handelt, der wohl als Sicherheitsrisiko einzustufen ist. Ob man damit dann über Symlinks oder mount --bind vielleicht sogar noch größeren Schaden im System anrichten könnte, übersehe ich im Moment nicht. Doch ich könnte mir das schon vorstellen.

Nachtrag:

Ich kann mir überhaupt nicht vorstellen, wie das GVFS Zugriff auf die UNIX-Dateirechte des Servers haben kann, ohne die UNIX Extensions zu verwenden. Und diese werden ja ausdrücklich vom GVFS nicht unterstützt! Doch die Extensions selbst können dies ja auch, nur weiß ich nicht, wie die das machen.

Einstweiliges Workaround: Ordner, die Root-Dateien bzw. allgemein fremde Dateien enthalten, niemals "persönlich" freigeben, weder mit "klick…klick", noch mittels "net-usershare add..." im Terminal!

Gruß – Max-Ulrich

Hallo.

Der Nutzer hat Schreibrechte im freigegebenem Ordner und Leserechte auf der Datei? Dann kann er mit den Standard-Unix Rechten die Datei lesend öffnen, die Originaldatei löschen und eine neue Datei mit gleichem Namen erstellen.

Daher ist das Problem hier meiner Meinung nach deutlich grundlegender, als bisher dargestellt.

Kleiner Test zur Verdeutlichung:

echo "Text1" > newTestFile # Datei erstellen
ls -la newTestFile         
chmod 400 newTestFile      # Schreibrechte entziehen
ls -la newTestFile
cat newTestFile            # Datei anzeigen (Inhalt "merken")   
rm newTestFile             # Datei löschen
echo "Text2" > newTestFile # Mit verändertem Inhalt neu anlegen 

Habt ihr dagegen schon etwas unternommen?

Viele Grüße

Vej

Hallo!

Ich habe damit noch nie gearbeitet, daher kann ich auch keine Erfahrungen dazu beitragen. Durch das Thema geweckt, habe ich mir aber mal die Sektion "USERSHARE" der Manpage angesehen und zitiere:

Starting with version 3.0.23, a Samba server now supports the ability for non-root users to add user defined shares to be exported using the "net usershare" commands. To set this up, first set up your smb.conf by adding to the [global] section: usershare path = /usr/local/samba/lib/usershares Next create the directory /usr/local/samba/lib/usershares, change the owner to root and set the group owner to the UNIX group who should have the ability to create usershares, for example a group called "serverops". Set the permissions on /usr/local/samba/lib/usershares to 01770. (Owner and group all access, no access for others, plus the sticky bit, which means that a file in that directory can be renamed or deleted only by the owner of the file)...

Ist das Verzeichnis bei euch mit den entsprechenden Rechten (01770) gesetzt?

Klingt für mich auf jeden Fall nach ner bösen Sicherheitslücke. Man stelle sich ein ausführbares root-Script mit frei änderbarem Inhalt vor → Vollzugriff aufs System.

Obwohl ich dringend was für Java machen muss...kommt doch heute Pinguin dran, nun den

Wieder hab ich heute etwas kurioses entdeckt, wo ich euch bitte, das mal gegen zu prüfen.

Ich hab den gleichen, simplen smb.conf Eintrag wie oben nochmals erstellt, diesmal jedoch für den Pfad /etc. Hintergedanke: Probieren (ist ja nur eine VM), ob ich als user nun auch Zugriff auf die wichtigen Bereiche des Systems hab z.b. die shadow Datei, gerade die kann mittels CUDA,dem ollen John und passwd einfach geknackt werden.

Also, gesagt getan. Der Host bei mir ist ein Ubuntu 1610 (der auf die Ubuntu 1604 Server VM zugreift), dort fand mein Dateimanager erst mal nicht direkt die neue Freigabe...eine gezielte Ansprache mittels dem cifs Pfad klappte allerdings auf Anhieb. Nun folgte ein direktes Alt+t für meine Konsole. Der Pfad ist tatsächlich im /run/user/1000/gvfs/smb-share:server=192.168.0.20,share=apocalypse, sprich, gvfs ist offensichtlich wieder involviert. Ein ll auf den Inhalt des /etc Ordners zeigte ÜBERALL USER:USER an und kein ROOT:ROOT ! Auf dem Server verblieb alles beim alten. Zur Kontrolle auch ein getfacl auf /etc als Ausgabe

1
2
3
4
5
6

# file: ..
# owner: user
# group: user
user::r-x
group::---
other::---

Das gleiche noch im Samba Ordner

1
2
3
4
5
6

# file: ..
# owner: user
# group: user
user::rwx
group::---
other::---

Neu ist jetzt, ich konnte trotz angeblichen Eigentums NICHTS öffnen oder gar editieren (getestet mit shadow), im Samba Ordner konnte ich die smb.conf öffnen, aber nicht editieren wegen mangelnden Rechten Wie bereits in meinen ersten Beiträgen ausführlich geschildert,...hab ich keine weiteren Änderungen in der smb.conf vorgenommen, ausser halt nun einen neuen share zu erstellen. Ich erwähne das nochmals, da mein erster share in /srv/testshare lag/liegt und genau da diese sehr gefährliche Sicherheitslücke besteht...den, egal ob Bug oder Feature, so einfach und ohne Vorwarnung darf root nicht überschrieben werden.

Mal abgesehen davon, das USER nicht als Eigentümer da stehen darf (völlig egal ob Rechte oder nicht)...kann es sein, das Samba den Pfad irgendwie wirr berücksichtigt?

Ich habe nochmal an anderer Stelle auf das Problem hingewiesen, um auch die Leute zu erreichen, denen das Wiki besonders am Herzen liegt: gvfs-mount. Ich finde, wir sollten uns ohne Hektik, aber trotzdem gründlich mit dem Problem befassen!

Im Übrigen stimme ich mit der Einschätzung von Vej und ChickenLipsRfun2eat voll überein.

Nun zum neuen Post von NetworkWarrior:

Der Pfad ist tatsächlich im /run/user/1000/gvfs/smb-share:server=192.168.0.20,share=apocalypse, sprich, gvfs ist offensichtlich wieder involviert.

Mit dem GVFS hat dies zunächst einmal nichts zu tun. Dies zeigt nur, dass net usershare involviert ist. Wir müssen genau unterscheiden: "net usershare" ist ein Samba-Tool auf dem Server, und das GVFS ist ein virtielles Dateisystem auf einem Client mit gtk-Oberfläche (GNOME, Unity, Mate, Xfcd, Lxde…,aber eben nicht KDE), mit dem sowohl lokale Partitionen als auch Netzwerk-Freigaben im Userspace (d.h. nicht systemweit) eingebunden werden können. An sich haben net usershare und GVFS direkt gar nichts miteinander zu tun, doch offenbar ergibt die Kombination beider eben Ungedeih.

dort fand mein Dateimanager erst mal nicht direkt die neue Freigabe...eine gezielte Ansprache mittels dem cifs Pfad klappte allerdings auf Anhieb

Wir müssen Zugriffe über das GVFS (also auch direkt über den Dateimanager) und Zugriffe über das cifs-vfs hier sauber getrennt halten, da sie sich völlig verschieden verhalten. Dies dürfen sie an sich auch, nur eben nicht gerade so!

so einfach und ohne Vorwarnung darf root nicht überschrieben werden.

Das darf es schlichtweg eben gar nicht!

kann es sein, das Samba den Pfad irgendwie wirr berücksichtigt?

Soweit ich feststellen konnte, geschieht das Ungedeih eben nur bei net usershare in Verbindung mit dem GVFS, sonst verhält sich Samba hier offenbar völlig korrekt. Solche Fehler, die nur bei bestimmten Kombinationen auftreten, sind recht schwer zu lokalisieren und einzuordnen. In diesem Fall hier wissen wir ja noch nicht einmal sicher, ob der eigentliche Fehler auf dem Server (net usershare) oder auf dem Client (GVFS) zu suchen ist. Deshalb hätte ich gerne noch ein paar Informationen mehr, bevor ich eine Fehlermeldung schreibe.

Gruß – Max-Ulrich

EDIT:

Nochmal zum letzten Post von ChickenLipsRfun2eat:

Ist das Verzeichnis (/usr/local/samba/lib/usershares) bei euch mit den entsprechenden Rechten (01770) gesetzt?

Dieses Verzeichnis gibt es nicht. Ein entsprechendes Verzeichnis wird bei der Installation von Samba mittels usershare path = /var/lib/samba/usershares automatisch in /var/lib/samba/usershares eingerichtet. Die Rechte sind, wie gewünscht, drwxrwx--T 2 root sambashare (=1770). Gilt für Ubuntu 16.04, Samba 4.3.11.

Klingt für mich auf jeden Fall nach ner bösen Sicherheitslücke. Man stelle sich ein ausführbares root-Script mit frei änderbarem Inhalt vor → Vollzugriff aufs System.

Schlimm ist das schon, aber sooo schlimm hoffentlich nun doch nicht.

Ich bin kein Hacker, dazu fehlt mir auch die Phantasie. Doch ich habe 'mal ein bisschen 'rumgespielt, um über diese Sicherheitslücke Zugriff auf's System zu bekommen. So ganz einfach geht das zumindest nicht:

• Als Erstes der Versuch, Systemdateien in eine Persönliche Freigabe hinein zu verlinken. Mit Symlinks, die ja jeder ohne Root-Rechte einrichten kann, geht da wohl nichts – ohne die Option wide links = yes, die man nur mit Root-Rechten eintragen kann, sogar mit Sicherheit nichts. Symlinks werden normalerweise übers GVFS einfach nicht erkannt und nicht angezeigt.

• Über Verdopplung des Mountpunktes mittels mount --bind kommt man natürlich auf die Systemdatei und kann diese dann auch "illegal" verändern. Doch mount --bind geht ja glücklicherweise nicht ohne Root-Rechte und nicht über smbclient, d.h. jemand ohne sudo-Berechtigung kann sich damit keinen Zugang zu Systemdateien verschaffen.

• bleibt noch das "illegale" Ausführen eines Root-Skripts. Ausführbare Root-Skripte erscheinen im GVFS nicht als ausführbar. Sie können deshalb über Samba zwar verändert werden (das ist schon schlimm genug), doch ausgeführt werden können sie über das GVFS nicht.

• Allerdings werden Root-Skripte innerhalb Persönlicher Freigaben, die über das GVFS editiert wurden, dadurch auch auf dem Server für gewöhnliche Benutzer editier- und ausführbar. Das ist auch schon recht böse!

Sicher haben Root-Dateien und speziell auch Root-Skripte innerhalb Persönlicher Freigaben eigentlich nichts verloren 😬 . Trotzdem sehe ich diesen Fehler zumindest als mittleres Sicherheitsrisiko an ❗ .

Ich hoffe sehr, dass das GVFS bei FTP und SSH (SFTP) die Dateirechte absolut sicher respektiert. Denn dort wäre ohne das Freigaben-Konzept die Gefahr noch viel größer.

Max-Ulrich_Farber schrieb:

Sicher haben Root-Dateien und speziell auch Root-Skripte innerhalb Persönlicher Freigaben eigentlich nichts verloren 😬 .

Ja. Das ist natürlich wieder eine sehr selten ausnutzbare Lücke. Root-Script im Freigabeordner und diesen per cron ausführen oder so. Problematischer ist die Tatsache, dass Berechtigungen einfach auf $USER:$USER geändert werden, falls man mit Gruppen arbeitet, kann man dadurch andere Nutzer aussperren.

Kannst du das mal versuchen? Also eine Datei mit chmod $USER:andereGruppe ändern, per Freigabe bearbeiten?

Kannst du das mal versuchen?…

Done. Und es passiert genau das, was ChickenLipsRfun2eat befürchtet hat. ☹

Und das passiert sogar dann, wenn die gesamte Freigabe einer anderen Gruppe gehört. Es wird also nicht etwa die Gruppe (bzw. der Eigentümer) der Freigabe auf die enthaltenen Ordner und Dateien übertragen (wäre ja im Sinne von "inherit owner ..." durchaus denkbar), sondern die Dateien sind nach dem (erlaubten oder auch unerlaubten) Editieren und Verändern immer Eigentum von $USER:$USER. Schlimm. Am Modus (chmod…) ändert sich hingegen nichts.

Mit ACLs habe ich jetzt noch gar nicht experimentiert. Es würde mich nun nicht mehr wundern, wenn sich da noch mehr Überraschungen auftäten.

Dieses Beispiel macht mir wieder 'mal deutlich, wie sehr das Sicherheits-Konzept von Linux durch die graphischen Oberflächen aufgeweicht wird. Ein Grund mehr, für alle Server, die in einer "feindlichen" Umgebung stehen bzw. die vom Internet aus zugänglich sind, dringendst von einer GUI abzuraten!

EDIT:

Der letzte Satz war leider vorschnell ausgesprochen. Auf dem Server werkelt ja in diesem Fall nur net usershare, das geht auch ohne GUI. Die GUI wird nur für das GVFS auf dem Client gebraucht, und Clients haben fast immer eine GUI. Der Verzicht auf eine GUI auf dem Server nützt also speziell in diesem Fall gar nichts.

Nun zur Zuordnung des Fehlers (wegen Bugreport): Ich neige dazu, den Fehler beim GVFS und nicht bei net usershare zu sehen, auch wenn beide zusammentreffen müssen, damit es passiert. Denn net usershare ist upstream weiter oben als das GVFS (?), d.h. das GVFS muss sich nach den Gegebenheiten von net usershare richten und nicht umgekehrt. Sehe ich das so richtig? Oder muss man argumentieren, dass jeder Server so geschützt sein muss, dass nicht irgend ein Client mit irgend einer GUI dort die Rechte durcheinander bringen darf? Dann wäre das ja eher ein Fehler von net usershare.

Danke fürs Austesten!

Ich würde den Bug bei net sehen, da dort ja in der Manpage (siehe Auszug oben) klar drinsteht, dass man beim Beachten der Regeln nur als Eigentümer die Berechtigung zur Änderung hat. Wenn eine andere Software das Umgehen kann, sehe ich die Lücke hier.

Ein Hinweis/tag der auf GVFS zeigt, wäre dennoch anzuraten, da es ja eine spezielle Konstellation erfordert.