Samba + Disztrib csere után - NT_STATUS_ACCESS_DENIED (Megoldva:apparmor )

SUSE Linux

Sziasztok, az alábbi témában kérném a segítségeteket, én kifogytam az ötletekből. Egy régi vasat cseréltünk egy korábbi Suse 9-ről openSUSE 11.4 (x86_64) "Celadon" verzióra. Azért erre, mert a céges ERP (PROGRESS base) ezen a verzión még működik más cégeknél. A hálózat csak belső hálózat, nincs internet. Minden klappol, viszont a Samba könyvtár megosztások az istennek sem működnek, a nyomtató megosztások viszont jók. A telepítés után hagytam az új disztrib configot, és csak a megosztásokat másoltam be a configba.

uname -a
2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux

Az smb.conf


[global]
workgroup = xxxxx
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = Yes
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = No
domain master = No
security = user
netbios name = mynetbios
wins support = Yes
realm = mynetbios.myworkgroup
template homedir = /home/%D/%U
winbind refresh tickets = yes
restrict anonymous = no
log level = 3
# DEPRECATED! share modes = yes
hosts allow = 127.0.0.1 192.168.x.x/24 ...
hosts deny = 0.0.0.0/0
interfaces = eth* lo
bind interfaces only = yes
passwd program = /usr/bin/passwd %u
encrypt passwords = yes
os level = 64 // set the OS level

[spooler]
path = /proteus/spl
read only = No
guest ok = Yes
[...]
...

A korábbi verzión minden gond nélkül működött. Ami a legfurcsább az egészben, hogy ha XP alól csatlakoztatni akarok egy mappát, akkor látszólag csatlakozik, de az XP kiirja:
"X:\ nem érhető el!
Hozzáférés megtagadva!"

Ugyanakkor linux oldalon ez látszik:

smbstatus
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf"
Processing section "[global]"
Processing section "[megoszt1]"
Processing section "[megosztx.]"
Processing section "[megosztxx.]"
..
Processing section "[minta]"

Samba version 3.6.3-115.1-2797-SUSE-SL11.4-x86_64
PID Username Group Machine
-------------------------------------------------------------------

Service pid machine Connected at
-------------------------------------------------------
spooler 1931 xxx1-pc Wed Jul 29 09:13:32 2015
spooler 1939 xxx2-pc Wed Jul 29 09:13:52 2015
spooler 1930 xxx3-pc Wed Jul 29 09:13:31 2015

No locked files

Valakinek ötlete???

  • 2655 megtekintés

( agostonl | 2015. 07. 29., sze – 13:12 )

Nem itt van a kutya elhantolva?
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)

Talán ez?

"Értem én, hogy villanyos autó, de mi hajtja?"

Szia, kipróbáltam, nem. Beírtam az /etc/security/limits.conf alá a szükséges sort: @group_name_for_your_samba_users soft nofile 16384
de mivel ez csak reboot után érvényesülne, még kiadtam az ulimit -n 34353 utasítást is, így már nem panaszkodik semmire. Az a röhej, hogy egy olyan könyvtárnál, ahol jó a megosztás, annak a beállításait átmásoltam egy másik megosztásra, és ugyanazokat a tulajt/jogosultságokat állítottam rá. Csatlakozik, meg is jelenik a mountolt mappa, majd kiírja,hogy hozzáférés megtagadva... Ezzel szorakozok már egész nap...

( wildy | 2015. 07. 29., sze – 15:23 )

Hmm... eleg nagy ugras volt, sok minden valtozott azota a samba beallitasaiban. Van pl. felhasznalo adatbazisod, mukodik az authentikacio?

Az aut működik, már lecseréltem a feni configot az smbpasswd-re. Viszont ha smbpasswd-vel jelszót cserélek, a sorban az első rész XXX-kel van kitöltve, és utána jön az encrypted rész. Már átnéztem a jogosultságokat a könyvtárakon, mindent többször is, de mondom, betűre ugyanazzal a beállítással az egyik megosztás működik (pont ami nem lenne lenne lényeges) és a másik meg nem. Még megnézem az egy hozzáféréshez max. kapcsolódható userek nincsenek e limitálva, de végképp kifogytam az ötletekből... :-(

hát ez az... a két könyvtár ugyanazé a felhasználóé, akinek a jelszavával csatolom, mindkettő 0777, és az egyik müxik, a másik meg szivat... Holnap nyugodtabban nekiállok, kimentek minden logot, és configot, újra neki futok... Ennek menni kell :-) Korábban nem guestként jöttek a felhasználók, hanem az smbpasswd-ben megadott felhasználókkal.

Ha nincs user adatbazisod, akkor a 'map to guest = Bad User' miatt mindenkibol guest lesz, es csak azok a dolgok mennek, amihez a guest is hozzafer, ezert tippeltem az authentikacio hibajara, nem az authorizaciora. A 'man 5 smbpasswd' hasznos olvasmany lehet, az elso (lanman) hash X-ekkel feltoltese elvileg lockolt felhasznalot jelent.

Az smbpasswd-ben ez van(ez a régi orig, ez lett bemásolva a samba könvtárába):

nobody:65534:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:[DU ]:LCT-00000000:
user1:uidszama:6E6B2142AE0FBA7BC2265B23734E0DAC:03ED867663555DA42847F0DCDCB35EB8:[U ]:LCT-442A6728:
user2:uidszama:1E6B4F89EDB4A874AAD3B435B51404EE:BED456D27E80FDEAA4F28BA8F5289BE1:[U ]:LCT-455045E1:
user3:uidszama:F44412EF5577E0A8AAD3B435B51404EE:FDF86CF0BF8F03B1D8D561CBBA8B9A2C:[U ]:LCT-448570CB:
user4:uidszama:15832B25FAA8399F25AD3B83FA6627C7:1795104DB412407EBB765CA823ED819C:[U ]:LCT-44858685:
user5:uidszama:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:[U ]:LCT-44868031:
user6:uidszama:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:[U ]:LCT-449FA257:
user7:uidszama:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:48C5AF89C3E006ADB94D17F48F974A5A:[U ]:LCT-55B91FA7:

A tesztet az user2-vel csináltam, és az ő beállításait másoltam az új megosztáshoz. A korábbi megosztás jó, az új nem. Valószínűleg igazad lesz, én nem ismerem ennyire a samba-t, csak egyszerüen nem tudom, mit kéne még beállítani, hogy az új megosztás is működjön.
Az user7 egy létező linuxos local felhasználó, ha jelszót cserélek, televágja x-el az elejét.

A samba conf most ez:

[global]
server string = OWN SAMBA
# PRINTER SETTINGS
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw

workgroup = myworkgroup
netbios name = mylinuxname

map to guest = Bad User
logon home = \\%L\%U\.9xprofile
logon path = \\%L\profiles\.msprofile
logon drive = P:
usershare allow guests = Yes
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
domain logons = No
domain master = No
security = user
template homedir = /home/%D/%U
restrict anonymous = No
log level = 3

interfaces = eth* lo
hosts deny = 0.0.0.0/0
hosts allow = 127.0.0.1 192.168.0.0/24

passdb backend = smbpasswd
encrypt passwords = Yes

ACL-t én nem állítottam be.
A megosztások igy néznek ki:


[jó_megosztás]
inherit acls = Yes
path = /home/valaki1/Export
read only = No
force group = users
force user = user2 //AZ SMBPASSWDBEN EZ VAN
guest ok = Yes
[rossz_megosztás]
inherit acls = Yes
path = /path1/path2
read only = Yes
comment = Comment
force group = users
force user = user2 //AZ SMBPASSWDBEN EZ VAN
guest ok = Yes

A /home/valaki1 ls -l kimenete:...drwxr-xr-x 4 user2 users 4096 2010 ápr 21 Export...
A /path1/path2 ls -l kimenete:...drwxrwxr-x 4 user2 users 4096 2010 ápr 21 valami...

Egyik jó, a másik nem. Nemcsak újrainditottam az smb-t, de a
smbcontrol all reload-config-t is használom változáskor.
Még egy, amit észrevettem, és nem értek. A yast-tal létrehozok egy új. linuxos felhasználót, majd hozzáadom az smpasswd-hez, (smbpasswd -a valaki) ugyanúgy xxx-kel rakja teli az első részt, mint az user7-nél. Miért?

+info:
Ma reggel még eszembe jutott, hogy a serveren kipróbálom a jelszavakat, hogy biztos legyek az authban.
Az smbclient //gepnev.workgroup/jo_megosztas -U user2 jó, enged belépni. it az "ls" is működik
Az smbclient //gepnev.workgroup/roosz_megosztas -U user2 enged belépni, de itt az "ls" NEM működik: NT_STATUS_ACCESS_DENIED listing \*

Ne a /path1/path2 tartalmat nezd meg, hanem magat a konyvtarat, azaz hasznald a -d opciojat is az ls-nek. Ha ott a user2-nek nincs x joga, akkor eppen az tortenik, amit latsz. Erdekessegkeppen megnezheted, hogy a 'valami' konyvtarba belepve minden oke-e - ennek most is mukodnie kene.

Az LM hash hianyaval ne foglalkozzunk, "enyhen" problemas biztonsagi szempontbol, jobb is, ha mar nyoma sincs. A guest hozzaferes engedelyezeset (usershare allow guests, restrict anonymous, guest ok) tuntesd el a konfigbol. SZVSZ jelenleg teljesen nyitott a gep.

Ha mar minden okes, akkor migralj mondjuk tdbsam-re. Egyetlen pdbedit futtatas kell csak hozza, nem nagy dolog.

getfacl /path1/path2
getfacl: Removing leading '/' from absolute path names
# file: /path1/path2
# owner: user2
# group: users
user::rwx
group::rwx
group:users:rw-
mask::rwx
other::r-x

EZ: "group:users:rw-" honnan jön???
Én direktben nem állítottam ACL-t, az eredeti beállításokat hagytam. (vagy akkor nagyon félreértek valamit :-) )

Johet a /path1 default ACL-jebol is (merthogy egy konyvtar default ACL-je oroklodik az ujonnan letrehozott elemekre). A 'getfacl -d /path1' megmutatja, mi van beallitva. Rekurzivan kell eltakaritani, ha van valami turpissag. Ha most mar mukodik a hozzaferes annak a felhasznalonak, akit a sambanal force user-kent beallitottal, akkor johet a samba share kiprobalasa. Az apparmor nem fog kotozkodni, mert az opensuse a samba indulasakor lefuttat egy scriptet, ami minden share path-ra engedelyezi a teljes hozzaferest az smbd-nek.


getfacl /path1
getfacl: Removing leading '/' from absolute path names
# file: path1
# owner: más_user
# group: users
user::rwx
group::rwx
other::---

Elvileg ennek igy is kellene lennie, a path1 egy program-konyvtár, ami a programozóé. Az alatta levő ./path2 lenne az user könyvtár, amit egy közös felhasználónévvel érnek el, az állományok eltérő felhasználóktól származnak, de mindenki az users group tagja. A régi verzióban ez gond nélkül működött.
Közben próbáltam azt is, hogy kikapcsoltam az ACL-t a
acl check permissions = No
acl group control = No
acl map full control = No
beállítással, de nem volt hatása...

Lemaradt a -d opcio, ez nem a default ACL. Ezek a samba opciok egeszen masra valok. Probalkozz azzal a unix felhasznaloval / csoporttal, amit a samba-nak megadtal (force user, force group), merthogy azoknnak sem kene hogy menjen a /path1/path2 konyvtar listazasa. Amig ez a helyzet, addig nem samba hiba, hanem filerendszer jogosultsagi problemad van.


getfacl -d /path1
getfacl: Removing leading '/' from absolute path names
# file: path1
# owner: user1 ### MÁSIK USER, a programozó
# group: users

Csak ennyi a kimenet.
Azóta még ezt is lefuttattam:

setfacl -m user:user2:rwx,group:users:rwx /path1
setfacl -m user:user2:rwx,group:users:rwx /path1/path2

getfacl -d /path1/path2
getfacl: Removing leading '/' from absolute path names
# file: /path1/path2
# owner: user2
# group: users
user::rwx
group::r-x
other::r-x

getfacl /path1/path2
getfacl: Removing leading '/' from absolute path names
# file: /path1/path2
# owner: user2
# group: users
user::rwx
user:toth:rwx
group::rwx
group:users:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:other::r-x

Létrehoztam egy teszt könytárat, másolt tartalommal, chown, setfacl beállítva, smbclient csatlakozva, ls kimenete: NT_STATUS_ACCESS_DENIED listing
Ez szerintem nem ACL. Valaki tudna mondani valami értelmezhetőt? :-)

OK, ha biztos vagy benne, hogy az adott felhasznalo jogosultsagai stimmelnek a filerendszeren, akkor lepjunk tovabb. Suse, tehat apparmor van hasznalatban. aa-status mit mond az /usr/sbin/smbd processz(ek)rol? Ha enforce modban van, akkor atmenetileg tedd at compain modba: aa-complain /etc/apparmor.d/usr.sbin.smbd
Ha meg igy se megy, akkor egyelore passz :(

( NevemTeve | 2015. 07. 30., cs – 10:04 )

Az nem gond, hogy az egyik helyen P: van, a másikon meg X: ?