Œ. Istnieje specjalny obiekl umowny onazwie [Public]. Formalnie nie
jest on
umieszczony w ¿adnym miejscu struktury NDS, ale za to ma specjaln¹ cechê
polegaj¹c¹ na tym, ¿e ka¿dy oMiekt w NDS ma takie same priypisania
dysponenckie
do katalogów, plików, innych obiektów i ich w³asnoœci jak on. Nawet nie
trzeba siê
do sieci zarejestrowaæ poleceniem LOGIN, by mieæ takie prawa jak [Public]!
Wystarczy tylko za³adowaæ oprogramowanie stacji w sieci. Zatem jakiekolwiek
nadanie dysponenckie dIa [Public] jest nadanicm dysponenekim dla wszystkich
u¿ytkowników sieci, nawet tych niezarejestrowanych. Daje to ³atw~ mo¿liwoœæ
udost‡pniania wszystkim u¿ytkownikom sieci niektórych obiektów w NDS lub
ich
w³asnoœci. Domyœlnie,je¿eli administrator tego nie zmieni, [Public]j‚st
dysponentem
obiektu [Root) z prawem Browse, dziêki czemu kn¿rly u¿ytkownik w sieci mo¿e
ogl¹daæ strukturê ca³ej bazy NDS.
4. Ka¿dy u¿ytkownik posiada w³asnoœæ o nazwie Securily Equivulenee co oznacza
"mn
tnkie ~~rnwci jnk ...". Jest to lista obiektów w strukturze NDS, których
prawa
dysponenckie posiada dany u¿ylkownik. Automatycznie zatem trafiaj¹ na t~~
listê
wszystkie grupy, do których ten u¿ylkownik nale¿y, obiekty typu
Organizational Role
tylko te, których funkeje polecono do wype³niania danemu u¿ytkownikowi
(patrz opis
obiektu Organizational Role w rozdzialc OMiekty NDS i ich W³~snoœci) i
wreszcie
przez jawne wpisanie na listê "równowa¿ników" innych u¿ylkowników, a nawet
dowolnych obiektów w NDS. Maj¹c wype³nion¹ w³asnoœæ Securily Equivalence
u¿ytkownik uzyskuje prawa dysponenckie, ale s~ to prawa nie jawnie mu
nadane lecz
"czyjeœ" (a dok³adniej obiektów wymienionych na liœcie Security
Equivalence).
str 81
systemem NetWare 4
Prawa dysponenckie podlegaj¹ czemuœ, co nazwane zosta³o dziedziczeniem. Niestety
(a mo¿e na szez‡œeie) s¹ a¿ dwa rodzaje dziedziczenia: dziedziczenie uprawnieñ
"od
swoich przodków" (ang. nncestory inheritnnc~) idziedziczenie polegaj¹ce
na
sp³ywaniu praw dysponenekich (ang. rightsf7ow).
edziczenie od swoich przodków polega na tym, ¿e jakiœ kontener (tutaj "przodek")
taje dysponentem dowolnego obiektu. Wtedy uprawnienia tego kontenera przechodz~
na
rarte w nim obiekty, które w ten sposób te¿ staj¹ si‡ dysponentami obiektu,
którego
ponentem jest ich kontener-przodek. Rysunek 6.13 pr Lybli¿a nieco ten mechanizm.
ATC
Create, Delere
SERWIS TECH
JAN TOM JAN DRUK
SUB SERW DRUK
SUB-1 SUB-2
6.13 D~iedziczenie upr-aH~nieri w rlrzewie NDS
~œæmy, ¿e kontenerowi SERWIS nadano prawa Create i Delete do kontenera TECH.
~ zarówno JAN i TOM w kontenerre SERWIS maj¹ te same prawa obiektowe do
iera TECH, czyli proœciej mówi¹c mog~ zak³adaæ i kasowaæ w nim obiekty. Maj¹
te
dlatego, ¿e mia³ je ich "przodek", czyli rodzimy kontener, a zatem
nast¹pi³o
;iczenie "po przodkach".
przypadek lo sp³ywanie praw (zwane te¿ czasem dziedziczeniem praw, ale nie
chodzi
odziedziczenie "po przodkach"). Je¿eli u¿ytkownik TOM zostanie uczyniony
nentem kontenera TECH przez nadanie prawa np. Write, to takie same prawo ma
on
e¿ w kontenerze SUB i dalej w kontenerach SUB-1 i SUB-2. Inaczej mówi¹c,
jego
ñienia "sp³ynê³y" od kontenera TECH do kontenerów le¿¹cych poni¿ej "a¿ do
dna"
~zo ciekawa rzecz pojawia si‡ w stosunku do dziedziczenia praw do w³asnoœci
obiektów.
¿ nie mog~ one dla pojedynezych w³asnoœci "sp³ywaæ" w dó³ struktury, poniewa¿
nie
¿adnej gwarancji, ¿e w obiekcie po³o¿onym ni¿ej w strukturzc te¿ istnieje taka
sama
5noœæ, jak w obiekcie po³o¿onym wy¿ej (chocia¿ w niektórych obiektach, a œciœlej
w
;ktach tego samego rodzaju, taka w³asnoœæ mo¿e rzeczywiœcie istnie‚). £atwo
natomiast
wa¿yæ, ¿e mog¹ sp³ywaæ prawa do wyjaœnionych ju¿ w pierwszym przypadku tzw.
ystkich w³asnoœci (ang. All Proper-ty). Przyk³adowo, je¿eli TOM móg³ zmieniaæ
ystkie w³asnoœci kontenera TECH, to nic nie nie œtoi na przeszkodzie, by m~g³
zmieniaæ
ystkie w³asnoœci ka¿dego obiektu po³o¿onego "wewn¹trz" kontenera TECH bez
kania w to, jakie w³asnoœci te obiekty posiadaj¹. Po prostu, mo¿e zmieniaæ
wszystkie,
e by one nie by³y.
str 82
82 Novell NetWare 4.0 - u¿ytkowanie i administro
A zatem wniosek dolycz¹cy sp³ywania praw do w³asnoœci obiektów jest nast‡puj¹cy
~
sp³ywaj¹ tylko prawa do wszystkich w³asnoœci (ang. Al! Proper-ty Righ~s), a do
poje-
dynczych w³asnoœci - nie. Co do praw lypu obiektowego, to sp³ywaj¹ one zawsze w
g³¹b
struktury.
Prawa dysponenta do obiektu (lubjego w³asnoœci) odziedziczone z konlenerów
nadrz‡dnych
mog~ zostaæ anulowane (czyli zmienione na inne), poprzez ponowne jawne nadanie
dysponenckie do tego obieklu (lub do jego w³asnoœci). Takie nadanie jesl
silniejsze od
dziedziczenia praw i powoduje, ¿e od tego obiektu pocz~wszy w g³¹b struktury (o
ile by³
to kontener) sp³ywaj~ tylko te prawa dysponenta. które pojawi³y si‡ w wyniku
tego nadania.
Sytuacja taka jest przedstawiona na rysunku 6.14.
ATC
SERWIS Create. Delete
TECH
JAN TOM JAN DRUK
SUB SERW DRUK
Browse
SUB-1 SUB-2
Rysunek 6.I4 Poclwójite rtncla~aia pruw dysponenekich
W tym przyk³adzie u¿ytkownik TOM otnyma³ poprzez jawne nadanie dysponenekie dwa
prawa obiektowe Create i Delete do kontenera TECH. Zgodnie z zasadami
dziedziczenia,
oba te prawa sp³ywtzj¹ na kontener SUá oraz dalej na kontenery SUá-1 i SUB-2.
Jednak¿e
w przypadku kontenera SUá-1 pojawi³o si‡ ponowne jawnc nadanie dysponenekie dla
u¿yll;ownika TOM, ale tym razem otriyma³ on lylko jedno prawo - Browse. Tym