[Hjälp sökes!] Unix Permissions med Samba?

Permalänk
Medlem

[Hjälp sökes!] Unix Permissions med Samba?

Tjenare, behöver hjälp med ett problem jag stött på. Nuvarande scenario ser ut som följande:

Server A - Ubuntu Server 16.04, delar ut shares med Samba
Server B - Ubuntu Server 16.04 mountar sharesen från server A via fstab
Server C - Ubuntu Server 19.04, nyuppsatt och ska ersätta server B.

I dag när jag mountar A-sharesen på B-servern så "ärver/respekterar" B-servern de unix-rättigheter som finns på filerna på A-servern, precis som jag vill att det ska vara. Det innebär att om Mapp 1 har 755 och Mapp 2 som ligger i Mapp 1 har 770 på server A så kommer rättigheterna i filträdet vara identiska som mountade shares på server B, capish?

Problemet uppstår när jag ska mounta A-serverns shares på C-servern. Det som inträffar då är att sharesen på C-servern får alla rättigheterna 755 root root, såväl parents som childs. Det innebär att en användare som tillhör "other" har inga möjligheter att komma åt Mapp2 på Server A och B men kommer åt mappen utan problem på server C då mappen likt alla andra har 755, vilket är helt åt helvete.

Jag har googlat lite och det enda jag hittat är typ att man ska mounta i fstab som en användare, det enda det gav var att rättigheter ändrades till 755 user root. Det har uppenbarligen skett en förändring kring detta i hoppet mellan 16.04 -> 19.04, någon linuxguru som kan rädda mig här?

Permalänk
Medlem

Vill du vara snäll och posta de två olika fstab-raderna. Från B (där det fungerar) respektive C (där det inte fungerar).

Visa signatur

Linux och Android

Permalänk
Medlem
Skrivet av Adoby:

Vill du vara snäll och posta de två olika fstab-raderna. Från B (där det fungerar) respektive C (där det inte fungerar).

Den är identisk på båda servrarna:

Server B:
//192.168.1.30/V4 /mnt/seedboxshares/V4 cifs credentials=/root/.smbcredentials 0 0

Server C:
//192.168.1.30/V4 /mnt/seedboxshares/V4 cifs credentials=/root/.smbcredentials 0 0

Observera att server C är Ubuntu Server 19.04, inte 16.04 som det stod i startinlägget innan jag redigerade det, my bad.

Permalänk
Medlem

En gissning är att något har ändrats i Samba-paketet. Du skulle kanske kunna testa att specificera att t.ex. version 1 ska användas istället och se om det gör någon skillnad.

//192.168.1.30/V4 /mnt/seedboxshares/V4 cifs credentials=/root/.smbcredentials,vers=1.0 0 0

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Medlem
Skrivet av noMad17:

En gissning är att något har ändrats i Samba-paketet. Du skulle kanske kunna testa att specificera att t.ex. version 1 ska användas istället och se om det gör någon skillnad.

//192.168.1.30/V4 /mnt/seedboxshares/V4 cifs credentials=/root/.smbcredentials,vers=1.0 0 0

Vilken hjälte alltså... Nu fungerar det exakt som på server B. Det här väcker ju dock följdfrågor, varför har man implementerat den här förändringen? Det är väl önskvärt att de unix-rättigheter som återfinns på server A respekteras när man mountar sin share? Är det en hållbar lösning att köra på en gammal version?

För en linux-amatör; är det Samba man använder sig av när man mountar sharesen? Jag var tvungen att installera paketet cifs-utils för att kunna göra detta.

Permalänk
Medlem
Skrivet av Matheeeew:

Vilken hjälte alltså... Nu fungerar det exakt som på server B. Det här väcker ju dock följdfrågor, varför har man implementerat den här förändringen? Det är väl önskvärt att de unix-rättigheter som återfinns på server A respekteras när man mountar sin share? Är det en hållbar lösning att köra på en gammal version?

För en linux-amatör; är det Samba man använder sig av när man mountar sharesen? Jag var tvungen att installera paketet cifs-utils för att kunna göra detta.

Nej, det är en dålig lösning. Smb v1 har flera problem och har på windows avaktiverats som default. Jag är för dåligt insatt för att specifikt uppge exakt problem, men det har diskuterats relativt nyligen på flera platser. Någon kan säkert bidra med mer information om varför det är en mindre bra idé.

Skickades från m.sweclockers.com

Visa signatur

Ryzen 5800x @ 32gb 3200mhz @ 7tb ssd @ 3060ti Fractal r5 @ Arch
i5 4670k @ 24gb 1600mhz @ Fractal r3 @ 12tb ZFS @ Truenas Scale
Thinkpad T450 @ i5 5300u @ 16gb @ 512gb ssd @ 24+48wh batteri @ Debian

Permalänk
Medlem

Nu vet vi åtminstone att felet ligger i själva Samba och ingen annanstans. Om jag inte är helt ute och cyklar så använder Ubuntu 16.04 Smb 4.3 medan Ubuntu 19.04 använder Smb 4.10, så du borde också kunna ändra i fstab så att du sätter vers=4.3 istället för 1.0 som jag skrev i det första inlägget.

Om det är en bugg eller en feature att permissions fungerar som det gör nu vet jag inte. Det är möjligt att de har gjort en medveten ändring och att du måste konfigurera annorlunda om du ska använda en senare version.

Visa signatur

AMD Ryzen 7 1700X 3.8 GHz 20MB | ASUS PRIME X370-PRO | MSI GeForce GTX 1080 Gaming X 8GB | G.Skill 16GB DDR4 3200 MHz CL14 Flare X | Corsair RM650x 650W

Permalänk
Medlem
Skrivet av noMad17:

Nu vet vi åtminstone att felet ligger i själva Samba och ingen annanstans. Om jag inte är helt ute och cyklar så använder Ubuntu 16.04 Smb 4.3 medan Ubuntu 19.04 använder Smb 4.10, så du borde också kunna ändra i fstab så att du sätter vers=4.3 istället för 1.0 som jag skrev i det första inlägget.

Om det är en bugg eller en feature att permissions fungerar som det gör nu vet jag inte. Det är möjligt att de har gjort en medveten ändring och att du måste konfigurera annorlunda om du ska använda en senare version.

Det gick inte att byta till 4.3, enl. "man mount.cifs" kan man byta till 3.11, 3.0, 2.1, 2.0, 1.0. Jag testade samtliga och hade samma problem med alla versioner förutom 1.0, som vad jag förstår inte är önskvärd att bruka. Hur återskapar man då min funktion med det nya tänket? Det går ju inte att helt sonika sätta permissions på mapparna efter att man har mountat dem.

Permalänk
Medlem
Skrivet av Matheeeew:

Vilken hjälte alltså... Nu fungerar det exakt som på server B. Det här väcker ju dock följdfrågor, varför har man implementerat den här förändringen? Det är väl önskvärt att de unix-rättigheter som återfinns på server A respekteras när man mountar sin share? Är det en hållbar lösning att köra på en gammal version?

För en linux-amatör; är det Samba man använder sig av när man mountar sharesen? Jag var tvungen att installera paketet cifs-utils för att kunna göra detta.

Samba är ju främst för Linux -> Windows men funkar ju även för Linux-Linux men man tappar viss kompatibilitet. För Linux-Linux så är ju NFS klassikern. Den har en viss säkerhetsproblematik man bör ha koll på, se t.ex. http://www.tldp.org/HOWTO/NFS-HOWTO/security.htm, är kompatibel med det mesta inom Unix/Linux och brukar komma med som standard i de flesta distar.

Andra alternativ är OpenAFS, Ceph, GlusterFS och Lustre. Har inte testat de senare, men man får bara beredd att läsa på en del om man ska köra nåt av dem.

Permalänk
Medlem

Har du prövat noperm eller perm?

Permalänk
Medlem
Skrivet av SAFA:

Samba är ju främst för Linux -> Windows men funkar ju även för Linux-Linux men man tappar viss kompatibilitet. För Linux-Linux så är ju NFS klassikern. Den har en viss säkerhetsproblematik man bör ha koll på, se t.ex. http://www.tldp.org/HOWTO/NFS-HOWTO/security.htm, är kompatibel med det mesta inom Unix/Linux och brukar komma med som standard i de flesta distar.

Andra alternativ är OpenAFS, Ceph, GlusterFS och Lustre. Har inte testat de senare, men man får bara beredd att läsa på en del om man ska köra nåt av dem.

Men det kan ju inte vara ett helt främmande scenario att man vill dela ut filer över nätet från Linux -> Linux med möjlighet att sätta rättigheter baserade på användare. Det är ju piece of cake att göra detta med en Windows-share med NTFS-rättigheter såväl på folders som subfolders.

Jag är okunnig inom NFS men efter snabb eftersökning så har jag förstått att man autentiserar sig med IP-adress och inte user/pass (mecka med Kerberos-lösning för detta enkla ändamål känns bara nej) vilket verkligen inte gör det möjligt att åstadkomma det jag vill. Har ni/du aldrig haft detta scenario?

Skrivet av Meto:

Har du prövat noperm eller perm?

Jag ska testa detta när jag kommer hem. Jag hittade även en forumtråd där en användare hade i princip samma frågeställning som jag, alltså att begränsa läsrättigheter på subfolders. Då hade det löst sig genom att lägga till raden hide unreadable = yes i sambakonfigen, fungerade dock inte för mig.

Permalänk
Medlem
Skrivet av Matheeeew:

Men det kan ju inte vara ett helt främmande scenario att man vill dela ut filer över nätet från Linux -> Linux med möjlighet att sätta rättigheter baserade på användare. Det är ju piece of cake att göra detta med en Windows-share med NTFS-rättigheter såväl på folders som subfolders.

Jag är okunnig inom NFS men efter snabb eftersökning så har jag förstått att man autentiserar sig med IP-adress och inte user/pass (mecka med Kerberos-lösning för detta enkla ändamål känns bara nej) vilket verkligen inte gör det möjligt att åstadkomma det jag vill. Har ni/du aldrig haft detta scenario?

Man autensierar sig med UID (användarid) och GID (gruppid) förutom IP-adress. Som användare på Linux/Unix ser du i princip ingen skillnad mellan en nfs-share och lokal disk.

Du ska alltså ha samma UID på varje konto/användare på alla datorer som har tillgång till nfs-sharen. Säkerhetsproblem 1A är då att är du root på en dator som man exporterat nfs-sharen till kan du skapa nya användare med godtyckligt UID och på det sättet komma åt den användarens filer på nfs-sharen. 1B är att det går att spoofa en godkänd IP om en sådan maskin skulle vara avstängd.

När NFS designades så fanns det inte på kartan att en bärbar dator kunde köra ett så avancerat OS som klarade NFS, dessutom måste man ha fysisk tillgång till nätverkskabeln (nåt wifi fanns ju inte heller)

Så kan ju funka hemma... men vill man ha bättre säkerhet så behövs tex kerberos.

Permalänk
Medlem
Skrivet av SAFA:

Man autensierar sig med UID (användarid) och GID (gruppid) förutom IP-adress. Som användare på Linux/Unix ser du i princip ingen skillnad mellan en nfs-share och lokal disk.

Du ska alltså ha samma UID på varje konto/användare på alla datorer som har tillgång till nfs-sharen. Säkerhetsproblem 1A är då att är du root på en dator som man exporterat nfs-sharen till kan du skapa nya användare med godtyckligt UID och på det sättet komma åt den användarens filer på nfs-sharen. 1B är att det går att spoofa en godkänd IP om en sådan maskin skulle vara avstängd.

När NFS designades så fanns det inte på kartan att en bärbar dator kunde köra ett så avancerat OS som klarade NFS, dessutom måste man ha fysisk tillgång till nätverkskabeln (nåt wifi fanns ju inte heller)

Så kan ju funka hemma... men vill man ha bättre säkerhet så behövs tex kerberos.

Ja herregud, då behöver man skapa alla användare i exakt samma ordning på alla maskiner annars faller alltihop, och root-problematiken är ju sannerlligen anmärkningsvärd. Man har ju en hatkärlek till Linux alltså, som seedbox är systemet oerhört kompetent men det här är ju under all kritik, motsvarande funktion hos konkurrenten Windows är ju en standardlösning.

Permalänk
Medlem
Skrivet av Matheeeew:

Ja herregud, då behöver man skapa alla användare i exakt samma ordning på alla maskiner annars faller alltihop, och root-problematiken är ju sannerlligen anmärkningsvärd. Man har ju en hatkärlek till Linux alltså, som seedbox är systemet oerhört kompetent men det här är ju under all kritik, motsvarande funktion hos konkurrenten Windows är ju en standardlösning.

Du behöver inte skapa användarna i samma ordning, man kan ju ange UID när man skapar kontot med adduser, alternativt kan man editera /etc/passwd och sen uppdatera fil-rättigheterna.

Så finns ju en orsak till att OpenAFS och de andra alternativen tillkommit. Funkar samba för dig så kan du ju köra det i stället.

Finns mer än en orsak till att man skrivit The Unix Haters Handbook

Permalänk
Medlem

Dålig på att uppdatera mina egna trådar och man hatar ju själv när någon har haft samma problem som en själv men inte återkopplat i trådar. Fick aldrig löst detta med permissions, det är ju helt sjukt att en användare på ett Linux-system via Samba kan komma åt filer som på ursprungsservern inte har permissions som tillåter detta.

Jag tog bort Samba ur ekvationen och satte upp en reverse proxy för FTP-användare som iställer kommer in direkt på Server A med SFTP, fungerar lysande.