másolás lehetőségének tiltása Windows Server-en

Microsoft Windows

Sziasztok!

Van-e arra valamilyen frappáns lehetőség, hogy Windows Server 2008 R2-n úgy beállítani egy fájl vagy könyvtár jogosultságát, hogy a domain user-ek olvasni tudják a tartalmakat, de másolni nem? Fájlrendszer NTFS.
Ezzel nagyon szépen meg lehetne azt oldani, hogy egy fájlról millió duplikáció készüljön.
Az ötleteket előre is köszönöm!

Nekem úgy tűnik, hogy a read jog nem különböztet meg olvasást és másolást, azt meg nem hiszem el, hogy egy ennyire triviáns igényt nem lehet normálisan megoldani?

( mauzi v | 2013. 07. 24., sze – 17:36 )

> Nekem úgy tűnik, hogy a read jog nem különböztet meg olvasást és másolást

A másolás = a forrásfájl beolvasása, és más fájlba kiírása...

A másolást végző ${RANDOM} program milyen rendszerhívát csinál szerinted? Fájl olvasást, és fájl kiírást. A fájl olvasást nem akarod tiltani. A fájl kiírást nem akarod tiltani. Akkor WTF?

Egy dolgot tehetsz, hogy korlátozod a gép(ek)en a futtatható programokat, és csak általad auditált programkódokat engedsz hozzáférni a tartalomhoz.

( wachag | 2013. 07. 24., sze – 17:37 )

Biztos vagy benne, hogy értelmeset kérdezel?

Képzeld el, szépen kiolvasod a tartalmát, majd beírod egy másik file-ba. Ha már olvasható, akkor másolható is.

Azt tudom, hogy működik, azt nem értem, miért csak így működhet? Miért nem szabályozható egy attribútummal pl.
Megnyitni lehet, másolni nem. Persze jobban fogy a háttértár, ha 5 fájl van rajta 150 példányban.
Azt hiszem az operációs rendszer rétege nem alkalmas normális dokumentumkezelésre.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Bzmeg. Az oprendszer a felhasználói szoftverek felé fájl tartalom olvasási, és írási képességet tesz lehetővé, úgynevezett rendszerhívások segítségével. Ezeket lehet engedélyezni, és tiltani.

Amiről te beszélsz, az már nem oprendszer feladatkör: tetszőleges felhasználói program, ami képes olvasni és írni, az képes másolni. Sőt, még írni sem kell tudni fájlba, elég ha van hálózati kapcsolat, és hálózati socketbe írsz... Akkor aztán nézhet nagyot az oprendszered, mert a "szerver" gép ilyenkor fájlszinten mást nem csinált, csak olvasott...

Bzmeg. Az, hogy mi oprendszer feladatkör, az csak azon múlik, hogy mit programoznak bele és mit nem.
Problémafelvetésem azon alapul, hogy jé, de jó lenne, ha egy eddig nem létező új funkció megvalósításra kerülne operációs rendszer szinten.
Az, hogy mit tud egy rendszer, nem jelenti azt, hogy mást nem is tudhatna.
Mivel Windows a szerver és mondjuk Windows a kliens is, nem lenne ám nagy művészet a Chess Titans-on felül értelmes funkciókat is leprogramozni. Nem az 50 éves hagyományokra kellene új felületet kitalálni, hanem új alapokra helyezni a műsort. Egy checkbox kérdése a szerveren: enable file copy? Yes/no
No esetén a szerver utasítaná a kliens-t, hogy ne tudjon írási műveleteket végrehajtani a fájllal, csak olvasásit. Nem Sci-Fi annyira... szerintem.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Tudom, hogy müködik az Office mentési processze, itt sem volt fejlesztési szempont az általam elképzelt funkció.

Azt kell lássuk, hogy a létezö jogosultsági rendszerek erösen korlátozottak.
Az alapfunkciók és azok filozófiája, müködési elvük mind-mind korlátozottak.

Addig vagy jó, amíg a korlátozások mellett ki tudod használni a rendszerekben rejlö képességeket úgy, hogy eszedbe sem jut, hogy te valami mást szeretnél, valami JOBBAT szeretnél. Ez van. Kocsival sem tudok repülni, pedig lehetne, ha megvalósítanák. Túl magasak az elvárásaim...

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

"No esetén a szerver utasítaná a kliens-t, hogy ne tudjon írási műveleteket végrehajtani a fájllal, csak olvasásit. Nem Sci-Fi annyira... szerintem."

Az a baj, hogy a másolat írása nem azon a fájlon történik, amit másolnak, ezért nem lehet megvalósítani. Azt nem tudja követni az os, hogy az a process, ami olvasott egy fájlt, majd ír egy másikat, abba ugyanazt az adatot akarja-e kiírni, amit kiolvasott. Például azért, mert mi van, ha az eredeti fájl végére hozzáfűzésre kerül további adat, így az új fájl nem tekinthető másolatnak. Arról már nem is beszélve, hogy milyen teljesítményvonzata lenne ennek az összehasonlításnak.

Attól, hogy valami alapvetően máshogy működne, mint ahogy jelenleg működik, még nem kell, hogy Ferrari legyen.
Csak egy funkcióról beszélek, nem valami hűde-jajde dologról.
Mint pl. a duplaklikk.

Úgy tűnik, hogy ezt a funkciót valóban tartalomkezelő rendszerrel kell megoldani.

Pedig, ha része lenne a mai op.rendszereknek a funkció, akkor pl. nem lehetne egy website-ot sem csak úgy lelopni, stb, a lehetőségek tárháza, illetve az adatvédelem is fejlődhetne. Lenne még hova fejlődni.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Az a legrosszabb, hogy nem veszed észre, hogy rosszul gondolkozol.
Olyan funkciót vársz el a fájlszervertől ami ellent mond azzal amire kitalálták, azért nem tud csak tartalmat megosztani mert nem erre való, épp úgy ahogy az FTP szerver sem erre való és egy levelező vagy adatbázis szerver sem erre való. A fájlszerver arra való, hogy fájlokat ossz meg, te meg nem a fájlt akarod megosztani csak a tartalmát erre meg inkább egy erre okosított webszerver alkalmas.

szerk. plusz poén az aláírásod :D

Akkor az FTP és a fájlszerver filozófiája is - biztonsági szempontból - alapvetően hibás. Vagy direkt az, tökmindegy. Én inkább védeném az adatokat a 21. században, mint megosztanám.

Kicsit elavult az FTP szabványa (is).
Mik lehettek anno a tervezés fő szempontjai? Látjuk ma. Elavult, nem biztonságos, stb...

Hogy lennének kifejlesztve az alapvető rendszerek, ha a mai követelményeket és elvárásokat elégítenék ki, és nem a több évtizedes hagyományokat?

Azért mert valami elavult, attól még lehet jó is. De nem ez a jellemző, mert változik minden. A rendszerek hegesztgetése meg látjuk, nem vezet sokszor a kívánatos eredményhez.

Ez olyan, mintha még mindig Ford T-Modell-el közlekednénk, mert az is gurul, arra lett kitalálva. Átfestjük, hogy modernebbnek hasson. De ha valaki messzebbre és gyorsabban akarna eljutni vele, az felejtős.
(Különben is Ferrarit szeretnék vagy mi).

Egyébként csak álmodtam egy olyan funkcióról, aminek abszolút lenne értelme, de egy olyan (szoftver)világban, ahol meghatározzák, hogy mit tehetsz és mit nem, az ember inkább ne is álmodozzon.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Az a baj (vagyis abba nem gondoltál bele), hogy a szerver a te példádban úgy akarja megvédeni az adatot, fájlt, weboldalt, akármit, hogy "megkéri" azt, aki letölti, hogy légyszi ne engedd ezt kiírni.
Ez akkor hatékony, ha a kliens van annyira jó fej, hogy ezt betartja.

És a gond az, hogy hiába lenne ez a funkció a mai oprendszerek része, ha bárki el akarná lopni ezeket az adatokat, nagyon könnyen tudna olyan eszközt készíteni, ami elkéri az adatot, aztán a ne_engedd_légyszi_kiírni kapcsolót figyelmen kívül hagyva már azt csinál vele, amit akar.

Ahogy írták többen is, helyi fájlrendszeren nagyon egyszerű: te magad is írhatsz olyan shell scriptet, C programot, vagy akármit, ami megnyit és beolvas egy fájlt. Ezután ennek a tartalmával már bármit csinálhatsz. Megjelenítheted képernyőn, kinyomtathatod, megnyithatsz egy másik fájlt írásra és beleírhatod a tartalmát, megnyithatsz egy hálózati kapcsolatot, és az adatot elküldheted máshová, egy másik gépen futó másik programnak.
Ezek közül a helyi operációs rendszer tilthat dolgokat. Pl. helyi fájl írást egyszerű tiltani. De ha mindent tiltasz: nem lehet semmit a képernyőre írni, nem lehet semmit nyomtatni, nem lehet semmit új fájlba beleírni, nem lehet hálózaton kommunikálni - akkor vajon milyen értelmes dolgot csinál a program?

Ugyanez a hálózati kommunikáció esetén még durvább: Egy weblap ellopását megpróbálhatod úgy megtiltani, hogy nem szabad megjeleníteni, lementeni, kinyomtatni, text-to-speech felolvasni. De akkor a weboldal felesleges, senki nem látja, nem tudja használni.
Ha bármit engedsz ebből, akkor már rögzíthető. A képernyő lefényképezhető, stb.
És akkor arról még nem is beszéltünk, hogy a hálózati forgalmat (mielőtt a kérésedet figyelembevevő böngészőhöz érne), le lehet menteni, de aki a weboldalt le akarja menteni, ír egy kis programot, ami http protokolt beszél, a webszerveredhez kapcsolódik és lekéri a weboldalt. Aztán meg azt csinál vele, amit csak akar.

Ugye azt tudod, hogy egy egyszerű nem titkosított weboldalt pl. kézzel egy telnet segítségével le lehet kérni. A képernyőn megjelenített adatokat meg akár manuálisan be lehet gépelni valahová, ha mondjuk a kijelölés és bemásolás, vagy egyszerűen a kimenet átirányítása nem működne.

Egyszóval: megoldható, hogy biztonságos legyen, de csak akkor, ha egyben használhatatlan is lesz.

Persze van lehetőséged titkosítást használni, DRM-et, zárt kódot - de akkor ez azt jelenti, hogy csak az általad készített böngésző lesz képes a titkos weblapot megmutatni.
Nem tudom, emlékszel-e mi volt, amikor a DVD még új techológia volt. Csak egy kis számú DVD lejátszó program létezett, a titkosítás titkos volt.

Ez az a világ, amit elképzeltél, csak mindenre.

És nézd meg, manapság mivel lehet egy DVD-t lejátszani, mi maradt a nagy titkosításból!

Tovább gondoltam, elméletben még mindig működik.
Kétféle felhasználó van:
- akinek van joga másolni,
- akinek nincs joga másolni

Első eset már megvalósult.
A második esetben nem csak a fájl másolását, úgymond írását, de a módosítását is tiltani kell, hogy kikerülhetetlen legyen a védelem.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Pedig a második probléma megoldása is triviális. Sőt, már nagyon régen meg is oldották.

Saját fájlformátumokat kell használni. Ennek hátránya, hogy ezen formátumok olvasásához, szerkesztéséhez és mentéséhez külön meg kell írnod a programokat. Sajnos nincs királyi út. :-( Tehát írnod kell egy szövegszerkesztőt, táblázatkezelőt, ... A dolog megkönnyítése érdekében választhatod a nyílt forrású programok megfelelő módosítását is. Ehhez célszerű olyan programokat választani, amelyek licence lehetővé teszi az ilyen típusú módosítást. Esetleg írhatsz konvertáló programokat is, amelyek az általánosan használt formátumokról a saját formátumaidra konvertálnak. Így a rendszer „beüzemelésekor” mindegyik régebbi állományt könnyedén be tudod illeszteni az új rendszerben. A konvertálás után az eredeti fájlokat törlöd, és ezzel meg is oldottad a problémát.

A részletek érdekében keress rá a „DRM” rövidítésre. A DRM használata mellett már megoldott, hogy a fájl másolása csak x alkalommal lehetséges. A teendő csak annyi, hogy az x értéket nullára állítod.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

> Azt hiszem az operációs rendszer rétege nem alkalmas normális dokumentumkezelésre.

:D

Tegyük fel, hogy a copy parancs tiltható is lenne. De mi lenne az a logika, ami megakadályozná egy elolvasott (= RAM-ban levő) fájl kiírását máshová mondjuk egy másik diszkre, vagy akár kopipaszta bele egy üres fájlba?

Ez igaz, de a megoldás lényege az lenne, hogy nem jöhetne létre egy fájlról végtelen számú másolat, akár más néven, akár módosított tartalommal, csak az adminisztrátor által engedélyezettek számára lenne teljes jog. Nem adatvédelmi megoldás lenne, hanem konzisztencia-megörzö. Aki jogosultság hiányában lemásolna egy ilyen fájlt, kapna róla egy parancsikont plusz megtekintési lehetöséget.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Ehhez arra lenne szükség, hogy a számítógépen a felhasználó gyakorlatilag semmilyen programot ne tudjon futtatni, csak az adminisztrátor által előre ellenőrzött és jóváhagyott programokat. Lehet ilyen környezetet kialakítani, csak kicsit is használható környezetet kialakítani annyira rettentő sok meló az előre ellenőrzések miatt (meg amiatt, hogy a standard programokat nem lehet ilyen környezetben megengedni, mivel rajtuk keresztül kontrollálhatatlan dolgokat tudna csinálni a felhasználó), hogy ilyet szinte sehol nem használnak. Vagy túl sok mindent megengednek, és akkor semmi eredményt nem értek el, vagy túl kevés mindent engednek meg, akkor meg nem használható a gép semmire se.

Ha helytakarékosság a cél, akkor deduplikáció, illetve webes felületen elérhető dokumentumkezelés, ahol a dokumentum létrehozása, mentése és törlése létező funkció, létrehozás esetén üresen jön létre a dokumentum, és copy-paste funkciót is tiltod - bár annak a felhasználók nem fognak örülni.

A másik lehetőség, hogy az "etalon" könyvtárban valamilyen verziókezelővel oldod meg a változások követését, és új dokumentum létrehozását az átlagos usernek használhatatlanul megnehezíted - csak a doksitár adminja hozhasson létre új állományt. Aztán ha nagyon elkezd utálni, akkor persze ne csodálkozz :-P

Nem is volt feladat, hogy a hálózatra tudjon írni, vagy ne tudjon.
Ha elolvasod az eredeti kérdést, az a feladat, hogy olvasni lehessen a fájlokat, de lemásolni ne.
Az nincs odaírva, hogy HOVÁ ne lehessen lemásolni, tehát én azt tételezem fel, hogy sehová nem szabad tudnia lemásolni a nyúzernek. Sem vágólapra, sem pendrive-ra, sem CD-re, sem e-mailben nem küldheti tovább, folytassam?
Ez pedig ebben a formában nem megoldott. 

openSUSE 12.3 x86_64, vagy ami éppen jön.

Megoldott. A CD-s gépre nem tud pendrive-ot felcsatolni, nincs írható média a rendszerben, a kliens csak és kizárólag a szerverrel tud kommunikálni, harmadik/külső géppel nem. Extra feature gyanánt még a vágólap, mint olyan is letiltásra kerül, vagy akár teljes egészében kimarad a kliens oldali implementálása - vagy csak x és y programokból lehet copy, és z valamint w programba pehet paste, egyéb irány nem. De ez a cd-s, full r/o környezetnek nem része.

( NEUROFiRE | 2013. 07. 24., sze – 18:19 )

Mi alapvetoen ketfelekeppen oldjuk meg a problemat: ha valami dokumentumrol van szo, akkor Sharepoint, fileserveren pedig kvota, azon belul azt csinalnak amit akarnak.
Ha siras van, hogy keves a hely, akkor pedig kapnak egy FSRM riportot (duplicate files, least recently accessed files, stb), tobbnyire egy 'bazdmeg, takaritsatok' jellegu kisero uzenettel.
Alternativ megoldas: a 2012 Server tud deduplikaciot:)

(BTW a trivialis igeny trivialis megoldasa: kepezni kell a felhasznalokat, tudom, eselytelen...)

( kallo | 2013. 07. 24., sze – 19:22 )

Rossz irányba mentetek el, szerintem ehhez valami webes alapú tartalom megosztóra lesz szükséged.
1. Úgy kell belőni, hogy jobklick meg kijelölés tiltva legyen, kb. képként jelenjen meg a kliens böngészőjébe.
2. a print screent meg kikapcsolod gpoból.

( ncc1701 | 2013. 07. 24., sze – 21:42 )

Külső file server kell, ha már ragaszkodsz a windowos userekhez, a külső file szerveren zfs fájlrendszert kell használni, az tud tömöríteni is, meg deduplikációt is kezeli. Onnantól ugyanazt a doksit annyiszor másolják, amennyiszer akarjék, csak 1x lesz meg a lemezen.

Mondjuk azt a kihívást, hogy csak egy "master" változatban maradjon a fájl meg, és ne hozhasson belőle senki sok különböző példányt létre, még ez sem oldja meg.

Tartalomkezelő kell az már bizonyos.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Az a gáz, hogy a másolás megakadályozására az sem biztosíték.
Nem ugrik be a neve, valami IBM szoftver volt, amivel egy rövid ideig volt szerencsém dolgozni (OnDemand Content Manager vagy valami ilyesmi), de amennyire még emlékszem rá, azzal sem lehetett megakadályozni a dokumentumok másolását, csak megnehezíteni lehetett.

Azért ezt gondold át. Ezt a triviális - muhaha - problémát. Ha az illető fel tud tölteni a tartalomkezelőbe, akkor tud másolatokat csinálni. Ha nem tud feltölteni, akkor csak olvasni tud, azt meg meg lehet csinálni a fájlrendszeren is (ro share, gondolom nem lehetetlen).

Amúgy mi épp ilyesmire fejlesztettünk saját rendszert, van pár a piacon, de az se csodaszer.

( uid_7086 | 2013. 07. 24., sze – 21:48 )

Szerintem natív windows eszközökkel semmi esélyed.
Ha dokumentumokról van szó, akkor valami dokumentum kezelő/arcihváló rendszert kell használni és ahogy itt valaki írta, lekvótázni a userek által elérhető területeket és ha jön a sírás, hogy elfogyott a hely, akkor jelezni, hogy nálatok is, töröljenek. :)
(persze meg fogják kerülni, ha mást nem, kisírják a főnökségnél, hogy igenis kapjanak több helyet, majd vesznek még diszket - tapasztalat :D)

( Swifty v | 2013. 07. 24., sze – 23:09 )

1. Az igényed nem triviális... Vagy nem értesz semmit az informatikához, vagy nagyon hülye módon tudsz kérdezni. Inkább a problémád írd le, mint azt amit úgy hiszel, hogy a megoldás.

Ahogy sokan mások is leírták, nincs olyan hogy másolás korlátozás... Olvasás és írás van.

Amit elgondoltál, simán elvérzik pl. ezeken is:
- kliens egy folyamata olvassa a szerveren egy fájl tartalmát, majd lezárja a fájlt, és nyit egy újabbat írásra, amibe beletolja a kiolvasott adatokat,
- vagy akár ugyanez, azzal megspékelve, hogy egy ZIP fájlt készít... amit ki is bont...

2. Ami segíthetne neked, az egy olyan FS, ami képes block-okat hash alapján nyilvántartani, és ismeri a COW fogalmát...

De ez nem hiszem, hogy WinFos alatt meglenne...

--
Debian Linux rulez... :D

:)

Ahhoz képest, hogy hülye módon kérdeztem, elég jól megválaszoltad.
Nem azért vérzik el a problémafelvetésem, mert megoldhatatlan, hanem azért, mert jelenlegi ismereteim szerint egyik rendszer müködési elve sem támogatja az elképzelt funkciót.
Informatikával kb. 19 éve foglalkozom töretlenül, szóval a "semmit nem értek hozzánál" egy kicsit elörébb vagyok.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Nem akarlak bántani, de...
Én is huszonöt éven át éltem IT-s munkákból (programozó, rendszergarázda, valamennyire DBA), de ettől még beszélek hülyeségeket. Egykori munkatársaim tanúsíthatják. :D
Tartok tőle, hogy jelen esetben veled is ez lehet a helyzet.

Amit megfogalmaztál (másolás megakadályozása) nem az op.rendszer feladata, nem is lehet az.
Valószínűleg páran leírták már: ha olvasni tudsz adatot, az olvasható formában megjelenik a kliensen, attól kezdve másolható. Ha másképp nem, papír és ceruza segítségével. :)
A duplikáció megakadályozására léteznek módszerek, ez viszont nem a jogosultság kezelő rendszer feladata.

Szóval végülis hogyan képzeled?

A kliens a kérésekor tájékoztatja a szervert arról, hogy másolni akar?

Ha igen, akkor gondold tovább:
- Hová szeretné másolni? Saját gépre, másik szerverre? Nem mindegy, mert lehet, hogy másik szerverre lehet másolni, vagy akár a saját pendrive-jára is... Vedd figyelembe, hogy adott esetben az is megtörténhet, hogy a kliens egy átmeneti könyvtárába szeretné másolni az adott adatot, mert mondjuk nincs elég memóriája... Mi történne ilyenkor??? Hogy adminisztrálnád??? (Szabad másolni bárhova, kivéve vissza a szerverre??? Sehova sem szabad másolni, csak adott szerverre, vagy annak adott könyvtárába?)
- Ha még az előbbieket valahogy meg is oldod... Mi van akkor, ha mondjuk két szerver vagy kliens újraindítás után jönne vissza az adat??? Ennek a problémának a megoldásához szükség lenne az adat életútjának ismeretére.... Hogy is tárolnád? Mitől/hány százalék változtatástól lenne egy adat ÚJ?

Vedd figyelembe, hogy a másolás nem elemi művelet, ezzel szemben a szerveren az áthelyezés igen !!! Honnan, hova... És valójában csak könyvtárbejegyzések mozognak, az adatok a helyükön maradnak...

A dolog másik oladala pedig az, hogy a szerver kiszámol az adat blokkjaira egy-egy hash-t... Ezek alapján az ismétlődő blokkokat nem kellene duplán eltárolni... Persze ez töblet munka a szerver részéről, de szerintem ez a járható út.

--
Debian Linux rulez... :D

Pl. hogyan definiálod a "másolás" fogalmát az operációs rendszer felé (aki végeredményben fájlrendszerrel, adatblokkokkal dolgozik).
Meddig számít csak olvasásnak és mikortól mondod rá, hogy másolási céllal olvas?
Olyan rendszert kitalálhatnál, hogy pl. a cp parancs futtatásához külön jogosultságra legyen szükség, egy unix like rendszeren. Windows-on a másolás eleve nem így megy, bár a copy-t talán ott is korlátozhatod.
De ezzel csak egyes programok végrehajthatóságát tudod korlátozni, nem az adatok másolását.
(megfordult a fejemben egy rövidítés: DRM ;) )

Ami meg végül kisült ebből az egészből, hogy végül is nem a másolást akarod meggátolni, csak azt, hogy a szervereden sok példány legyen mindenből, arra írtak elég sok tippet.

Amit akarsz azt nagyjából úgy lehetne megoldani, ha a Microsoft bevezetne egy új API-t Win32 szinten, amivel meg lehetne kérdezni, hogy a kérdéses fájl a policy szerint másolható-e vagy sem, és minden alkalmazásfejlesztő becsület szavát adná, hogy a másolás jellegű műveletekhez ezt az új API-t használná engedély kérésre mielőtt ténylegesen végrehajtaná a fájlműveleteket. Ez az "önbevallós" rendszer kb. pont a te problémád oldhatná meg, azaz nem biztonsági, hanem szervezési problémát.

( hokuszpk | 2013. 07. 25., cs – 07:53 )

pcforumra a kerdessel, ott biztos megszakertik.

Hát persze.
Mint azt már sokan leírták előttem: ha valakinek engeded, hogy elolvasson valamit (vonatkoztass el a számítástechnikától), akkor azt tovább is tudja adni.
Ez a problémakör hasonlít a VPNes- (ahol internetkapcsolatot akarnak is meg nem is), illetve a "titkosítsunk valamit végtelen időre" threadre (Úgylátszik a nyár rossz hatással van a szakmára).

Nem technikai a megoldás. Információba szőtt metainformációból (vízjel) tudsz következtetni a másolóra, ezalapján később felléphetsz ellene jogi úton. Ha a kérdés arra irányulna, hogy Windows szerverre létezik-e ilyen transzparens vízjelfelvivő, nyilvántartó, akkor megérteném.

Ha a helyspórolásra vonatkozik a kérdés vagy félmegoldás keresésre, akkor már meg is kaptad a válaszokat másoktól (deduplikáció, illetve futtatható programok korlátozása).

Ha meg akarsz bénítani egy szervert összehasonlításokkal (vajon milyen beolvasott információ kerül kimenetre (hálózatról nem is beszélve)), akkor pusztán kényelmetlenséget okozol a felhasználónak, hiszen ekkor papírral ceruzával kell másolnia, illetve használhatatlanul lassú lesz minden.

Előbb magadban tisztázd a kérdést, bár szerintem csak unatkozol.

( rts | 2013. 07. 25., cs – 08:52 )

Elég sokan write only módban tolják. Ezt imádom a hupban.

Deduplication: Win 2008 R2-ről van szó. Ebben nincs deduplication. Van viszont egy buta lehetőség (Single Instance Storage) de ez nem igazi dedup és itt nem segítene. Másrészt nem az a kérdező gondja, hogy elfogy a hely, tehát ez egyáltalán nem megoldás.

Sharepoint: ha Office fájlokról van szó, ez a te barátod. (Mint már írták ezt is.)

Mint már tucatnyian leírták, a fileszerver nem ismeri a másolás fogalmát. Megfelelő lenne az a megoldás, hogy megadott mappákban átlag user ne hozhasson létre új fájlt, csak a már meglévőt írhassa?

( gangol | 2013. 07. 25., cs – 10:18 )

Végig olvastam a fórumot.

megpróbálom egyszerűen:
Azt kéne megértened hogy a ha egy 3. program azon a szerveren ahol a hálózati megosztásod van felolvas egy filet a diskről akkor ki is tudja írni azt valahova. Socketre, másik fileba. Már azt sem lehet ellenőrizni hogy ugyanaz a program ne írja ki a diskre ugyanazt a filet más néven. Azt írtad 19 éve informatikus vagy. Biztos kaptál némi bertekintést a programozásba is. Te hogyan ellenőriznéd hogy a futó program milyen adatod ír ki a diksre? Tudsz erre bámilyen használjható algorimust kitalálni? A program kiír valami adatsorozatot, hogy ellenörzöd hogy nem ugyanazt a filet írja ki 1 byte módosítással?

Illetve gondold végig kérlek hogy mi történik ha a megosztaáson keresztül olvassa fel a filet valami kliens. A file szervered csak felolvassa a filet . Szerinted hogy tudna ellenőrzést gyakorolni a kliens felett a fileszerver?

Szerintem ahogy mások is írták írd le a problémát amire megoldást keresel és olvasd el a javaslatokat. A kérésed emlékeztet arra amikor a felhasználó fotósoppot akar telepíttetni a gépére és amikor megkérdezem hogy mire kell akkor az a válasz, hogy képeket nézegetni.

Ha csak a helyet szeretnél spórolni akkor aduplikátumokra a dedup valóban jó megoldást lehet, de javaslom járj egy kicsit utána mert nem mind arany ami fénylik.

P.
freeop@freemail.hu

"...felolvas egy filet a diskről akkor ki is tudja írni azt valahova. Socketre, másik fileba"

Jelenleg ez törvényszerü, de nem feltétlenül kellene ennek így lennie. Azonban lehetne pl. az adatot csak memóriában tárolni. Azaz, hogy ne is tudja azt kiirni valahová. Se socket-re, se másik fájl-ba. Beolvasni és megjeleníteni, jogosultság birtokában másolni, kiírni, törölni.

A file-szerver kapna egy igényt a klienstöl, hogy ezt a fájl-t meg akarom nyitni.
A fájl beolvasásra kerülne a szerveren, és megjelenítésre a kliens-en. Olyan szerver-kliens közötti kapcsolat lenne, ahol az applikáció, pl. a Word ellenörízné a "copy" funkcióhoz rendelt jogosultságot, és ha nincs, akkor csak megjelenítené azt. Explorer úgyszintén, stb...

Ha nem rendelkezet "copy" joggal, nincs értelme a fájl-t módosítani, mert úgysem tudom lementeni sehová. Csak megtekinteni. Azt hiszem egy új attribútum alkalmazás szintü kezeléséröl beszélek.

"Szerinted hogy tudna ellenőrzést gyakorolni a kliens felett a fileszerver?"

Minden müveletnél szaladgálnak kliens-szerver között a SID-ek, authentikáció céljából. Az ellenörzés folyamatos kliens-szerver között, kérdés, hogy mit ellenöriz éppen a windows. Felhasználói jogosultságot, csoportjogosultságot, ACL-t, stb...

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

> Jelenleg ez törvényszerü, de nem feltétlenül kellene ennek így lennie.

Sajnos de, erről szólt eddig az egész thread.

> ahol az applikáció ellenörízné a "copy" funkcióhoz rendelt jogosultságot

Ez addig működik, amíg valaki nem ír egy "applikációt", ami le se szarja a copy jog meglétét. Vagy valaki ki nem heréli a nyílt forráskódú, így erre lehetőséget adó LibreOffice-t, hogy ignorálja a copy jogot.

Mondjuk lassan már nem teljesen világos, hogy helytakarékosság vagy infosec okokból tiltanád a másolást. Ha ez utóbbi, akkor esélytelen az ügy, ha az első, akkor nyilván lehet tiltani a visszaírást, de játszik a deduplikáció is.

Hát ja, mivel minden ellenőrzés a kliens oldalon lenne, ezért a megkerülése semmiből nem állna.
A kérdező amúgy DRM-et akar megvalósítani most (lejátszhatod a DVD-t, de nem másolhatod, ugyanez a problémakör), pár okos ember már töri ezen a fejét egy ideje, de mindig a userhez kerülő eszköz a gyenge láncszem ebben az egészben.

PDF-ben is van ilyen, aztán ez milyen már:
http://manurevah.com/blah/en/blog/Okular-and-DRM

:)

Egyrészt úgy tudom, hogy be lehet állítani úgy a remote desktopot, hogy csak windows-ból tudjon belépni rá a delikvens, a domainhez tartozó userrel, akkor meg korlátozhatóak a jogai a lokális gépén is (GPO), köztük a printscreen és hasonlók is.
(jó, fényképezőgép ellen nem véd)
Másrészt itt adatmásolásról volt szó, nem képernyőképekről.
Nagy mennyiségű adat esetében egy idő után valószínűleg feltűnne a kollégáknak, hogy miért van a beépített ügynök mobiljának kamerája a képernyő felé fordítva. :)

( saxus | 2013. 07. 25., cs – 17:14 )

Ezt nem lehet másképp kifejezni:

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( maszili | 2013. 07. 25., cs – 17:41 )

Ez a probléma általános érvényű a tartalom szolgáltatás területén és nem oldható meg a fájlrendszer szintjén.

Ha a kliensnek / programnak hozzáférése (olvasás) van a tartalomhoz és a kliensre / programra bízod a tartalom további sorsát (tartalom megjelenítés / kliens tárolhat tartalmat bármilyen adattárolón) akkor a tartalom lemásolható mert nincs befolyásod a kliens működésére.

Erre szokták azt kitalálni, hogy kötelezően olyan klienst / programot kell használni a megjelenítésre ami befolyásolható pl. DRM, stb. által.

--
maszili

( Hunger | 2013. 07. 25., cs – 17:51 )

Még nem említett kifejezések, amelyre léteznek termékek és megoldható velük többé-kevésbé az alapproblémád, amennyiben az az információmozgás kontrollálhatóságának kérdésére irányult:

- "Content Monitoring and Filtering (CMF)"
- "Information Protection and Control (IPC)"
- "Data Leakage Prevention (DLP)"
- "Information Leak Detection and Prevention (ILDP)"

Stb.

Érdemes figyelembe venni viszont, hogy biztonsági szempontból ezek nem nyújtanak 100%-os megoldást, sok szempontból kijátszhatók, de jogi eljárás esetén ekkor már nehezebb ráfogni az esetre, hogy csupán "hanyag kezelés" történt.

Egy részüket már az Office beépítve is tudja egyébként (pl. copy/paste tiltása, mentés máshova tiltása, print screen tiltása, stb.).

Azt tegyuk hozza, hogy a DLP elmeletben nagyon szep, gyakorlatban viszont hasznalhatatlan fos. Igen meretes logisztikai cegnel voltam tanuja a pilot-nak (nekem szerencsere nem sok kozom volt hozza), majd az ugy jogi utra terelesenek a projekt sikertelensege altal okozott anyagi karok miatt. A hivatalos eladok nem tudtak semmi ertelmeset mondani a problemakra, csak hogy hat ize, majd jo lesz ez, csak vegyunk SSD tombot a szervereinkbe, meg technikai limitacio, meg blabla.

A kerdezonek illene vegre tudomasul vennie, hogy ami egyszer megjelent a kliensen, az onnantol duplikalhato. Teljesen tokeletesen mindegy, hogy milyen attetes formaban, de megoldhato. Kb. ugy viselkedik, mint egy teljesen laikus manager, aki keptelen megerteni, hogy alapveto dolgok hogy mukodnek, "nem erdekel, oldd meg!". Amit el akar erni, az lenyegeben a DRM (ami egyebkent szinten megkerulheto). Nem hinnem, hogy ezt meg fogja tudni oldani onerobol.

Viszont a problemara letezik gyakorlatban elterjedt megoldas, de az nem technikai, mint inkabb jogi, es ugy hivjak, hogy NDA.

( uid_720 | 2013. 07. 25., cs – 18:07 )

Régen az NTFS nem támogatta a szimlinket. Ma támogatja.
Ehhez az kellett, hogy egy cég letegyen némi pénzt a MS asztalára.

Nyilván van az a pénzmennyiség, amiért az MS megoldja a "másolás" problémát.

Fuszenecker_Róbert

A szálnak csak az elejét meg a végét olvastam el, de eléggé zsibbasztóra sikerült mit ne mondjak. Kicsit olyan érzésem van, mint ha a kérdezőnek távolról se lenne köze az informatikához, pedig nagyon elszántan ért hozzá. (Ha bárkit megsértettem volna ezer bocsánat)

( Oregon | 2013. 08. 02., p – 12:30 )

Ez de jó! hrgy kollégád, vagy az osztálytársad volt logika órán? :)