Ļaut rakstīt vai nerakstīt kaut kādā mapē, atļaut vai liegt pieeju printerim nosaka tā lietotāja tiesības, kas programmu laiž (IMHO tādai būtu jābūt labajai praksei). Kas attiecas uz instalēšanu, tad tai vispār būtu jābūt super priviliģētai darbībai, kurai defaultā būtu jābūt aizliegtai, kā redzi honeybee tieši uz šī grābekļa uzkāpa.

Palaid setup.exe kā admins, un pēc tam tā proga varēs darīt to kas nu tavam lietotājam būs atļauts.

(Reply to this) (Parent) (Thread)

Bet ja nu setup.exe ir vīruss? Ne vienmēr ir laba doma dot installatoriem tiesības vienādas ar administratora tiesībām.

Šādā situācijā vairums lietotāju vienkārši vienmēr un visur izmantotu priviliģētus kontus, lai nebūtu lieki jāievada logins+parole kad vajadzīgas papildus tiesības. Man ir aizdomas, ka daudzi tā jau dara ;)

Dažām programmām ir obligāti darbam nepieciešamas tiesības, kuru parastam lietotājam nebūtu (piemēram diska defragmentācijai vajag tiešu pieeju diskam).

Nez', es, piemēram, nesen pieinstalēju Outpost Firewall & tā mēdz uzdot visai interesantus jautājumus - piemēram, vai atļaut kādai programmai izmantot OLE mehānismus un vai viena programma drīkst palaist citu, nemaz nerunājot par visiem specifiskajiem tīkla programmu gadījumiem (pārlūks, e-pasta klients, Skype, Shareaza, ftp klients & serveris, Apache, php, mysql...).

(Reply to this) (Parent) (Thread)

Tev taisnība, ka operētājsistēmās nevar iztikt bez programmām, kurām nepieciešamas visādas tiesības, tanī pat laikā jānodrošina, lai šīs programmas varētu darbināt jebkurš lietotājs neatkarīgi no savām tiesībām (tavs piemērs ar defragmentētāju, lai gan es nevaru iedomāties kamdēļ būtu jāatļauj defragmentētāju laist parastajam mirstīgajam, bet nu mans piemērs būtu paroles nomainīšanas proga). Šajām supervarenajām progām sistēmā jābūt pēc iespējas mazāk un pēc iespējas vienkāršākām un mazām. Lai pēc iespējas mazāka varbūtība, ka kāds varētu tās eksploitot.

Tas ka iekš setup.exe var slēpties vīruss ir fakts, bet tu pats augstāk minēji, ka setup.exe vajadzētu varēt piekļūt reģistrijiem, iekopēt savus DLLus sistēmas mapē utml. Pie šādas instalātoru visvarenības ar ko tad viņi no adminiem atšķiras?

Par labu superuseriem windowsā esmu dzirdējis šādu argumentu:
Windowsā (un pats MS to ir atzinis par problēmu) daudzi developeri nemākulīgi (cik nu nemākulīgi, bet arī paši vienmēr būdami admini) taisa progas kurām, itkā vajadzētu strādāt ar restriktētajiem useriem, bet kuras strādā tikai zem admina. Atceros uz W2K nekādi nevarēju palaist Blood2 zem restriktētā usera (ar adminu viss bija OK), lai gan citām līdzīgām gāmēm (Unreal, Half-Life) tādas problēmas nebija.

Piemēram honeybee puikam būtu mātei jāizlūdzas, lai viņa atļauj šim spēlēt blood2, t.i. piešķir atbilstošās tiesības blood2 spēlēšanai, tad viņš varētu turpināt nodarboties ar savu postošo darbību.

(Reply to this) (Parent) (Thread)

Mana nostāja principā ir tāda, ka, ja grib vienmēr atļaut tikai to, kas ir droši, lietotājam būtu jāzina par visu, kas notiek sistēmā & jāatļauj/jāaizliedz tas (bet to darīt nav praktiski). Pretējā gadījumā kādam/kaut kam vienmēr būs vairāk tiesību nekā minimāli nepieciešams.

Mjā, nemākulīgie programmētāji. Man ir aizdomas, ka arī viens mans softs nestrādātu iekš limited account (k-gan "power user" ir ok). Ne vienmēr ir iespējams k-kādu funkciju realizēt tā, lai tā būtu pieejama arī neprivileģētiem lietotājiem (šajā gadījumā DLL injection). Jā, varētu jau uzraxtīt servisu/draiveri, bet tas ir grūti & tad jātaisa arī instalators un programma vairāk nav pārnesama (portable). Drīzāk jau "slinkie developeri" :)

(Reply to this) (Parent) (Thread)

DLL injection ir eksotika, pirmo reizi par kaut ko tādu dzirdēju, palasīju, un nesaprotu kamdēļ tai būtu jābūt priviliģētai darbībai - injecto savam restriktētā lietotāja processam klāt kādu kodu gribi, tāpat šis nevarēs darīt vairāk kā viņam ļauts. Vai arī es neesmu kaut ko sapratis par to injectošanu?

Galu, galā, MacOS taču ir taisīts vislabākajās unix tradīcijās ar ļoti restriktētiem useriem, bet es neesmu dzirdējis nevienu sūdzamies, ka šis būtu baigi neērts.

(Reply to this) (Parent) (Thread)

Nez', MacOS neesmu savām acīm redzējis.

DLL injection ir ļoti parocīga noteiktu lietu realizēšanai & galvenokārt jau ar to, ka DLL injecto citos procesos, ne savā. Tādējādi var tiem procesiem likt k-ko darīt vai, piemēram, pārtvert API funkcijas (to dara lielākā daļa antivīrusu u.tml. programmu).

(Reply to this) (Parent) (Thread)

Nu es biju to domājis tā: "Kāpēc koda injectošanai no viena restriktētā procesa, kuru tu esi palaidis otrā restriktētā, tevis palaistā procesā, būtu nepieciešamas superusera privilēģijas?"

Man tiešām grūti strīdēties par šo jautājumu, jo DLL injectošana man ir tikpat sveša kā antivīrusu programmas.

(Reply to this) (Parent) (Thread)

Lai atbildētu uz šo jautājumu nāktos ļoti iedziļināties DLL injection darbības principos... Īsumā - viena no metodēm, ko izmanto DLL injection, ietver sevī cita procesa atmiņas izmainīšanu ar Windows API funkcijām kuru izsaukšanai ir nepieciešamas noteiktas tiesības, kas no limited user palaistam procesam parasti nav.

Anyway, tie jau ir sīkumi.

(Reply to this) (Parent) (Thread)

Unixā ir tā, ka process var smurgāties pa otra procesa memu, ja abus procesus ir palaidis viens un tas pats useris, tobiš, ja kaut kas ir aizliegts, tad ir aizliegts abiem un nekādu kaitējumu (ārpus attiecīgā lietotāja tiesībām) viņi bakstot viens otru nevar nodarīt. Vienkārši es neizprotu, kamdēļ zem windows, priekš tā ir jābūt super userim.

(Reply to this) (Parent)

SPAMERI, BĻE!

:D

(Reply to this) (Parent) (Thread)

;P

(Reply to this) (Parent)

Tas ir viņš, tas ir viņš, kurš visu laiku cenšas prierādīt, ka "pati muļķe", es jau neko, es tikai tevi aizstāvu!

(Reply to this) (Parent)