[Samba / Linux permissies] Vaag permissies probleem Ubuntu

[FireDrunk]

Om toch maar eens de beveiliging van mijn NAS (Ubuntu 12.04) op te poetsen ben ik aan het stoeien geslagen met fatsoenlijke permissies op mijn shares en data.

Ik heb een basis Ubuntu installatie met 1 user genaamd: thijs. Er is dus (Ubuntu default) ook een gelijknamige groep.

Mijn data (MD array) is gemount onder /mnt/data en momenteel heeft alle data chmod -R 770 gekregen.
Met andere woorden, thijs en thijs mogen erbij, meer niet... Ik dus...

root@NAS:/mnt# ls -la
total 16
drwx------  4 root  root  4096 Aug 18 21:20 .
drwxr-xr-x 23 root  root  4096 Aug 10 07:07 ..
drwxr-xr-x  2 root  root  4096 Jul 23 21:37 cdrom
drwxrwx--- 19 thijs thijs 4096 Aug 14 23:22 data
root@NAS:/mnt#

Mijn samba config:

[data]
        path = /mnt/data
        writeable = yes
        valid users = thijs
        create mask = 0660
        directory mask = 0770
        public = no
        browseable = yes
        inherit acls = yes
        inherit permissions = yes

En je raad het dus al, het werkt niet. Vanaf mijn windows desktop, die dezelfde username en password heeft als de user thijs op mijn NAS, krijg ik direct een permissions denied.

Iemand die snapt wat ik verkeerd doe? Ik heb al geprobeerd om ACL's te zetten setgid van groepen te doen en weet ik wel niet nog allemaal meer, maar het word alleen maar erger.
Het is net gelukt om het weer een beetje schoon te krijgen om met input van hier opnieuw te kunnen beginnen

- Thijs

[jan99999]

http://www.chuonthis.com/...-permissions-inheritance/
Misschien heb je hier iets aan.

[Verwijderd]

Volgens mij moet je van thijs ook een samba user maken. Hoe je dat kan doen is hier te vinden:

http://www.cyberciti.biz/faq/adding-a-user-to-a-samba-smb-share/

[ Voor 32% gewijzigd door Verwijderd op 18-08-2012 21:58 ]

[FireDrunk]

Is gedaan.

[ Voor 84% gewijzigd door FireDrunk op 18-08-2012 22:00 ]

[Verwijderd]

Ik denk eerder :

code:

sudo smbpasswd -a thijs

[FireDrunk]

Heb overigens al die xacl opties gebrobeerd, helpt allemaal niets helaas.

[Hero of Time]

Zet op die map eens o+rx. Dus other read en execute, maar dan alleen op de hoofdmap, niet recursief doorvoeren. Krijg je dan nog steeds permission denied? Samba draait namelijk als aparte gebruiker en als je iets afschermt met user:group, en niets anders, kan geen andere gebruiker, inclusief samba, er niet bij om te lezen. Jij wel, maar dat is niet voldoende in dit geval, de service die 't voor je beschikbaar stelt moet 't ook kunnen lezen.

Heb je ook al gekeken naar andere oplossingen dan Samba? SMB is namelijk traag als je niet aan optimalisatie sleutelt. En dat is niet het gemakkelijkst om 't uiterste er uit te krijgen. NFS is wellicht makkelijker om te doen.

Je kan iig voor Samba nog "valid user = thijs" zetten bij je share. Of iets waarmee je opgeeft dat alleen die gebruiker er bij mag.

[FireDrunk]

Maar ik wil juist niet other rechten geven, want ik wil andere users op de linux machine (gewone users) juist geen toegang geven tot die data. Het werkt dan inderdaad wel.

Is het niet beter om dan met een ACL de Samba user specifiek rechten te geven?

Ik weet overigens dat SMB traag is, maar NFS op windows is niet veel beter

[ Voor 13% gewijzigd door FireDrunk op 19-08-2012 12:10 ]

[Hero of Time]

Er is al het een en ander gezegd over hoe Samba werkt met gebruiker en rechten. Heb je nog niet de conclusie getrokken om de samba gebruiker aan jouw groep 'thijs' te hangen zodat dit probleem is opgelost, en dat je share verder afbakenen dat er maar 1 gebruiker aan mag melden? Dan bij deze .

[FireDrunk]

Samba draait onder root zie ik nu (Ubuntu default). Moet ik dan echt root aan de groep thijs toevoegen?

[Hero of Time]

Je mist het punt hier, en services zoals die draaien NOOIT onder root. Als jij ze onder root ziet draaien, dan is dat het eerste stukje voordat het schakelt naar unprivileged. Apache draait toch ook onder www-data? Maar initieel wordt het onder root gestart .

[oxtan]

samba draait zeker als root (dit in een debian stable host, maar het werkt overal op dezelfde maniert):

# ps auxwww | grep mbd
root 1254 0.0 0.2 9252 1468 ? Ss Aug13 1:30 /usr/sbin/nmbd -D
root 1258 0.0 0.3 16532 1908 ? Ss Aug13 0:00 /usr/sbin/smbd -D
root 1267 0.0 0.2 16520 1032 ? S Aug13 0:00 /usr/sbin/smbd -D
root 8088 7.3 0.7 17344 3912 ? S 12:30 2:13 /usr/sbin/smbd -D

Daarom zijn samba cve meestal kritisch :-) (zie http://www.samba.org/samba/security/CVE-2012-1182 bij voorbeeld).

[ Voor 0% gewijzigd door oxtan op 22-08-2012 13:05 . Reden: typo ]

[Hero of Time]

Als dat zo zou zijn, dan waarom werkt het niet als 'other' geen read rechten heeft? Root heeft volmacht, dus als een map 700 heeft, zou 't alsnog moeten werken. Pas als de map 755 is, kan Samba erin. Dit geeft aan dat Samba NIET als root draait. Zie ook:

$ ps auxwww | grep smbd
nobody   18646  0.0  0.0  95120  3952 ?        S    Aug21   0:21 /usr/sbin/smbd -D
root     27057  0.0  0.0  64580  1916 ?        Ss   Jul12   5:30 /usr/sbin/nmbd -D
root     27062  0.0  0.0  94720  3244 ?        Ss   Jul12   0:00 /usr/sbin/smbd -D
root     27066  0.0  0.0  94600  1480 ?        S    Jul12   0:00 /usr/sbin/smbd -D

Goh, wat zou de eerste lijn toch betekenen? Samba draait hier als 'nobody', juist om geen systeem rechten te hebben.

Waar al die CVE items over gaan, zijn issues op andere plekken en tijden van het starten, dan het daadwerkelijk kunnen serveren van bestanden. Dat laatste gebeurt dus als 'nobody' en vereist dus dat 'other' lees rechten heeft op een map.

[oxtan]

ik had het niet over rechten op de share. Ik reageerde op jouw bewering dat het niet als root draait. Beter lezen :-)

De output van jouw commando is anders dan die van mij, als je goed op let. De andere 3 smbd processen zijn eerder opgestart dan de eerste en ze draaien wél als root.

Het proces nr 18646 is opgestart door de gebruiker nobody waarschijnlijk omdat het een share betreft dat door iedereen benaderd mag worden zonder authenticatie. Zie dit:

# ps auxwww | grep mbd
root 1254 0.0 0.2 9252 1468 ? Ss Aug13 1:32 /usr/sbin/nmbd -D
root 1258 0.0 0.3 16532 1916 ? Ss Aug13 0:00 /usr/sbin/smbd -D
root 1267 0.0 0.2 16520 1040 ? S Aug13 0:00 /usr/sbin/smbd -D
pcpatch 13159 1.9 0.7 17344 3984 ? S 15:15 0:01 /usr/sbin/smbd -D

De gebruiker pcpatch heeft een share benaderd. Er wordt dus een proces opgestart voor die gebruiker. Maaaaar. ... de andere root processen blijven want zonder die processen kan je geen bestanden delen via cifs met samba

[Hero of Time]

Klopt. Maar jij beweerde dat Samba voor het delen als root draait (althans, dat begrijp ik eruit), en dat is dus niet waar. De core draait dan als root, het share proces zelf krijgt andere rechten. Daarom kan hij 'm niet benaderen met z'n eigen gebruikersnaam als authenticatie, want de share wordt met lagere privileges geopend.

[FireDrunk]

En dat is dus fout. Ik heb user mapping ingeschakeld naar Linux users. Met andere woorden: voor elke user die op een share aanklopt moet er eenzelfde Linux user bestaan (en dat vind ik prima).

Wat gebeurt er daarna? De user word geimporsonate, maar de group niet... En daar gaat Samba in mijn optiek de mist in... Ik heb het hier met collega's overlegt en die vonden het ook vreemd. In een boek vond ik dat als je dit wil, je de optie force group kunt meegeven zodat Samba altijd probeert of je lid bent van een bepaalde groep. Maar of dat de bedoeling is... Want dan vraag ik me af of als ik een linux user pak die niet in die groep zit maar wel bestaat, of samba die user dan nog steeds toegang tot de share geeft.

[oxtan]

Domme vraag misschien maar is de WORKGROUP instelling wél dezelfde voor alle twee hosts?

Probeer met net use vanuit je window pc:

net use \\nas\share /user:workgroup\user

Vervang workgroup door de naam van je workgroup, uiteraard

[Oid]

code:

[global]
 load printers = no
 show add printer wizard = no
 printcap name = /dev/null
 disable spoolss = yes
 browseable = no
 server string = 
 socket options = TCP_NODELAY
 default = homes
 workgroup = firedrunk
 os level = 20
 interfaces = 127.0.0.1 eth1
 security = user
 preferred master = no
 passdb backend = tdbsam
 bind interfaces only = true
 available = no

[data]
        path = /mnt/data
        writeable = yes
        valid users = thijs
        create mask = 0660
        directory mask = 0770
        public = no
        browseable = yes
        inherit acls = yes
        inherit permissions = yes
        available = yes

kan je eens proberen


voor dit soort rot klusjes gebruik ik altijd www.webmin.com omdat het simpel is, daarna pleur ik het er weer af maar het werkt wel

[Joseph]

Gek genoeg heb ik niemand om logs horen vragen.

Post die log eens?

[ Voor 25% gewijzigd door Joseph op 22-08-2012 23:26 ]

[Big Mama]

code:

root@NAS:/mnt# ls -la
total 16
drwx------  4 root  root  4096 Aug 18 21:20 .
drwxr-xr-x 23 root  root  4096 Aug 10 07:07 ..
drwxr-xr-x  2 root  root  4096 Jul 23 21:37 cdrom
drwxrwx--- 19 thijs thijs 4096 Aug 14 23:22 data
root@NAS:/mnt#

Als user 'thijs' kun je nooit bij /mnt/data komen, omdat je niet door /mnt heen kunt.
Doe eens een "chmod go+rx /mnt".

[FireDrunk]

Die fout had ik inderdaad al opgelost, maar daarna werkt het nog steeds niet.
In de logs staat dat thijs (op id) geauthenticeerd word, maar daarna zie ik niets qua denies.
loglevel van samba staat op 3.

[Thc_Nbl]

als ik naar deze kijk :

path = /mnt/data
en path heeft als rechten 770 ( data map )

wat heeft /mnt dan, als je daar namelijk 770 ook van gemaakt heb, ga je er niet bij komen.
zet maar eens 775 op /mnt en je kan bij je share..

of
je login van je pc is niet thijs en/of deze heeft geen wachtwoord.

zet onder samba er een wachtwoord op en maak eens een netwerk drive aan via windows met een ander aanmeld gebruiker.

en er van uitgaande dat
smbpasswd -a thijs
en
smbpasswd -e thijs
gedaan is.

-e = enable user.

[FireDrunk]

Gister dit allemaal gedaan:

/mnt op 775
/mnt/data op 770 (recursief)

@ smb.conf
valid users: thijs
force group: thijs

samba herstart, desktop herstart.

Geen effect, word nog steeds geweigerd. Zodra ik de share op 777 zet kom ik er weer vrolijk in.

[Thc_Nbl]

doe eens chown thijs:thijs /mnt/data
chmod 2770 /mnt/data

als dat niet werkt, kom je nog steeds als guest binnen.

wat als je :

net use x: \\servername\data /user:thuis jepassword

doet, werkt deze wel ?

[FireDrunk]

Wat is het verschil? Want mijn desktop heeft hetzelfde password?

[Hero of Time]

Het verschil is dat je zeker weet dat je als gebruiker thijs op de share aanmeld, en niet stiekem gast.