Hát nem mondanám meg neked, még akkor sem ha csak ketten nyernénk, ugyanis nekem 2 Mrd nem elég ! Nekem 4 Mrd kell, bár inkább több kéne... Szóval abszolút nem vagyok elájulva az összegtől, bár azt elismerem hogy azért annyit megér hogy az ember befáradjon egy lottózóba és kitöltsön egy szelvényt. És tudod mi a legfontosabb dolga aki megnyeri ? Törje a fejét kegyetlenül hogy több pénzt csináljon belőle !
Na szóval az umask úgy van hogy...
Igen az vagyok ! Amúgy ezen kívül még minden sz@rral is foglalkozom. Most a legújabb dolog ami foglalkoztat a heti lottószámok kitalálása a húzás előtt legalább 1 nappal. Már nyomon vagyok, nemsokára lesz eredmény, ha majd halljátok hogy végre volt ötös... Akkor már aztán annyira rá fogok érni hogy napi 2 órát csak umask-magyarázattal töltök az index-fórumon, további 2 órát az OODB fejlesztésével foglalkozom, éjszaka pedig az erdőt járom. Lásd: bemutatkozó fotóm ! Ja és még kell napi 1 óra hogy leugassam a winfos-hivőket.
Nem baj, éppen az umask-kal kinlódtam tegnap és éppen körül akartam nézni a témában. :-)
Civilben gondolatolvasó vagy? :-)))
Akkor csak a tanulság kedvéért a probléma.
Van egy DICOM szervercsomagból egy program (storescp), ami csücsül a 104-es porton és fogadja a DICOM (MRI,CT) képeket. Nem tesz semmi mást, mint a DICOM protokoll alapján küldött képeket lepakolja egy kijelölt könyvárba.
A feladat az volt, hogy egy doki a képeket le tudja tölteni otthon ftp-vel. Miután letöltötte törli, a képeket.
Mivel a 104 portot csak root joggal lehet használni, a file-ok is a root felhasználó és root csoport tulajdonába kerültek. Így ftp-vel a felhasználó nem tudta törölni az állományokat. A root umaskja 022 volt.
A programot indító scriptet az alábbira módosítottam:
umask 000
storescp .....
Így már a felhasználó tudja törölni az állományokat.
P.S.: Mondjuk adatvédelmi szempontból nem a legkorrektebb a megoldás, ezen még finomítani kell.
setuid dir: nincs hatasa: mármint hol nincs? Ugyanis pl. az én rendszeremben van. Ím a részlet a /sys/i386/conf/LINT nevű fájlból:
# If you are running a machine just as a fileserver for PC and MAC
# users, using SAMBA or Netatalk, you may consider setting this option
# and keeping all those users' directories on a filesystem that is
# mounted with the suiddir option. This gives new files the same
# ownership as the directory (similar to group). It's a security hole
# if you let these users run programs, so confine it to file-servers
# (but it'll save you lots of headaches in those cases). Root owned
# directories are exempt and X bits are cleared. The suid bit must be
# set on the directory as well; see chmod(1) PC owners can't see/set
# ownerships so they keep getting their toes trodden on. This saves
# you all the support calls as the filesystem it's used on will act as
# they expect: "It's my dir so it must be my file".
#
options SUIDDIR
(Persze ha eddigi megnyilvánulásaimból nem lett volna világos, ez FreeBSD :-)
sticky file: linuxban semmi kulonos: no ez legalább korrekt, hogy Linuxban nincs (bár ezt speciel én nem tudom); rövid kiegészíts: általában Jujnikszokon ennek az a hatása, hogy ha a program befejezte futását, akkor a kódja (régi nevén: TEXT-szegmens) kikerül a SWAP területre, és a legközelebbi futáskor már onnan lehet betölteni (ez bizonyos okokból gyorsabb lehet, mint ha fs-ről kéne). (Zárójelben: itt is vannak finomságok, van (van még?) olyan Jujniksz, ahol bizonyos tipusú EXE-k esetén a sticky nem a SWAP-re rakta a kódot, hanem fizikailag a RAMba ragasztotta be, ahonnan nem is swap-pelődött ki.)
Uff, én beszéltem.
Zahy
Köszönjük az összefoglalót, a "setuid dir","setgid dir","sticky file"-t meg nem mondtam volna ha rákérdezel.
Egyébként a "sticky dir"-re a legjobb példa amit mondani szoktak a /tmp, hiszen oda aztán mindenki ír de egymás file-jaihoz nem nyúlunk szabály érvényesül:
$ ls -ld /tmp
drwxrwxrwt 9 bin bin 5120 Jan 22 14:23 /tmp
setuid file: ha executable, a futas alatt az EUID a file-user-e lesz
setuid dir: nincs hatasa
setgid file: ha executable, a futas alatt az EGID a file-group-ja lesz
setgid dir: a benne letrehozott file group-ja a directory group-ja lesz (egyebkent a letrehozo process GID-je (lasd newgrp))
sticky file: linuxban semmi kulonos
sticky dir: ha a konyvtar x tulajdona, es van benne y-nak egy fileja, azt csak x,y vagy a root torolheti, mas nem, meg akkor sem ha van write joga a konyvtarra
Hát én nem nevezném a pontatlanságra való figyelmeztetésnek azt a beszólást amivel elkezdted a kis csatározásunkat, idézem mit írtál:
gratulálok, hogy sikerült egy újabb szót megtanulnod: ugye milyen jól hangzik az umask? amúgy a jelentését is ismered? nem ártana mondjuk legalább egy mant elolvasni, mielőtt hencegni kezdesz a nemlétező tudásoddal
Ez a mondatod meg tényleg PONTATLAN:
legalább NevemTeve+zahy révén egy csomó mindent megtudtam
úgyhogy helyesen így hangzik:
legalább NevemTeve+zahy+altvizsla révén egy csomó mindent megtudtam
Rossz hírem van: ilyet (általam ismert, sztenderd) UNIX eszközzel nem tudsz megcsinálni, mert ezt a programozó kódolja bele a programjába (ahogy az a topicindító beszélyben szépen le vagyon írva); azaz max a Mozilla forrásban tudnád beállítani :-(
Sorry,
Zahy
Huh, ha igy vagod a temat, akkor erre is tudnal valaszolni?
Minden program fajlmentesnel ezek a jogok:
644
De Ha Mozillaval mentek fajlt, akkor meg ezek: 600
Es ez zavaro(hogy mindig lementes utan at kell chmod-olnom)
Hol allithato be, hogy egy alkalmazad adott joggal mentsen le(hozzon letre) egy uj fjalt?
Nem világos a kérdésből, hogy Te nem tudod az s és S jelentését, vagy a kollegától kérded. Tehát: az r, w és x karaktereken kívül jogosultság esetén még általában s (S) ill. t (T) betűk láthatók, melyek jelentése (sajnos) attól is függ, mely felhasználói kategóriánál látod az adott karaktert. Az s/S-ek vagy a Set-UserID, vagy a Set-GroupID bitet jelentik, attól függően, hogy a tulaj, vagy a csoport x joga helyén látod, míg a t az un. Sticky ("ragadós") bit. Az, hogy kis- vagy nagybetű, az pedig attól függ, hogy az ugyanazon a helyen ábrázolt futtatási (x) bit létezik, vagy nem:
- akkor, ha sem az execute, sem a spéci bit nincs beállítva;
x akkor, ha csak az execute van, a spéci bit nincs;
s (vagy t), ha execute is és spéci bit is;
S (vagy T), ha execute nincs, de a spéci bit igen.
A SUID, SGID, Sticky jelentését most nem magyarázom, egyszerre legyen elég ennyi. (Megjegyzem, néhány ilyen szempontból vad Jujnikszban találhatók eléggé különös lehetőségek, pl. van olyan, ahol a group helyen álló S egyfajta zárolást jelent, nem azt, amit a fenti szerint kéne.)
Zahy
milyen eljárással éred el, hogy umask 066 esetén rwx------ joga lesz egy file-nak
1. Ez egy elírás volt akkor részemről, mivel általában 066 esetén rw------- joggal jön létre, az "x"-et véletlenül írtam.
2. Ennek ellenére létre tud jönni egy file 066 umask mellett is rwx------ joggal ha a program így akarná. Pl. én/te is írhatnánk olyan C-progit ami egy 766 -os joggal akarna létrehozni file-t. Ekkor a kernel a 766-ból leveszi a 066-os umask által meghatározott biteket (végülis a 766-ot a 066 inverzével ÉS kapcsolatba hozza), és íme az eredmény 700 vagyis rwx------
A winfosozásról egyvalami derült ki semmi más: SZAR A WINDOWS (csak nehogy ebben a topicban erről kezdjünk el beszélni)
nézd, magyarázd el nekem, milyen eljárással éred el, hogy umask 066 esetén rwx------ joga lesz egy file-nak. másik topik 1836-ban ugyanis ezt állítottad. lehet, hogy nagyon hülye vagyok, de szerintem csak 711 vagy 600 lehet a létrehozott file/könyvtár, de 700 semmiképp
a kulturáltságot meg tőled is el lehetne ám várni...
emlékezz csak, hogy jöttél a winfosozással így meg úgy, azt kiderült, hogy csak nem értesz hozzá...
Azért nyitottam ezt a topic-ot mert úgy látom több embernek van hibás elképzelése az umask-ról, továbbá egy másik topic túl sokat tartalmazott már ebből a nem odavaló témából. A történet úgy kezdődött hogy valaki felvetette, hogy az ő dolgait ne lássák más userek, erre én megkérdeztem tőle: "csak nem umask 066-ot használsz ?". Erre best kolléga hülyének nézett, azért mert az umask-ról hiányos ismeretei voltak.
Akkor lássuk a medvét: az umask után egy 3-jegyű szám adható meg (hasonlóan ahhoz amikor chmod-nál 3 számjegyet adunk meg), és ezzel azt definiáljuk, melyek azok a jogok melyeket az ezután létrehozott file vagy könyvtár NE KAPJON MEG ! Vagyis azokat a jogokat ahol 1-es bitet írtunk elő az umask-ban. Például egy umask 672 azt jelenti hogy a létrejövő file/könyvtár esetén a usernél nincs r,w jog (6=4+2), group-nál nincs r,w,x jog (7=4+2+1), továbbá other-nél nincs w jog (2).
Az hogy a többi joggal mi lesz azt NEM TUDJUK, hiszen ez már nem az umask-tól függ hanem attól hogy a létrehozó program milyen jogokat szán a file/könyvtár-nak. Fenti példa alapján így tehát lehetséges hogy other-nél van x-jog, de az is lehet hogy nincs !
Álljon itt egy olyan példa amit egy unix-os gépen csináltam:
$ umask
022
$ mkdir teszt1
$ ls -ld teszt1
drwxr-sr-x 2 oracle dba 512 Jan 21 12:44 teszt1
$ umask 777
$ mkdir teszt2
$ ls -ld teszt2
d-----S--- 2 oracle dba 512 Jan 21 12:45 teszt2
$ umask 000
$ mkdir teszt3
$ ls -ld teszt3
drwxrwsrwx 2 oracle dba 512 Jan 21 12:46 teszt3
Az is belátható hogy az umask nincs kihatással a setuid,setgid,sticky bitekre hiszen ha ezekre is tudna hatni akkor nem 3, hanem 4 számjegyet lehetne umask-nál megadni. Gyengébbek kedvéért: teszt1 esetén a group-nál van x-jog, csak mivel a setgid bit 1-re van állítva, "takarásban van az x". teszt2 esetén viszont hiányzik az x-jog, így nagy "S" betű áll azon a helyen. Hozzáteszem hogyha valaki a példámat kipróbálja egy másik gépen nem biztos hogy ugyanezeket a jogokat fogja tapasztalni. Ez azért van mert az umask-kal csak azt tudjuk elérni, milyen jogok NE LEGYENEK az új objektumnál, ezeken kívül a többi jogra nincs az umask hatással.
Várom a kritikákat, észrevételeket, KULTÚRÁLT FORMÁBAN (jó példa: NevemTeve) !
