Küsimus:
Kas minu õigused domeenile / usr / local / õiged on õiged?
Agos
2010-09-10 15:07:37 UTC
view on stackexchange narkive permalink

Kasutan oma pordivajaduste jaoks HomeBrew (tundub natuke puhtam kui MacPorts).

Ma saan installida ilma sudo ingita (mis on suurepärane), kuid mees linkimise samm näib seda nõudvat ( / usr / local / share / man / man3 kuulub root ).
Leitud juhend soovitab mul rekursiivselt chown / usr / local teha

  sudo chown -R `whoami` / usr / local  

Kas see on ohutu ... või on see halb idee ™?

Samuti: kas minu õigused on õiged?

  $ pwd / usr / local / share / man $ ls -lahtotal 32drwxrwxr-x 8 root personal 272B 4 Set 11:02 .drwxrwxr-x 9 root staff 306B 10 Komplekt 11:27 ..drwxr-xr-x 3 juurratas 102B 4. aprill 2009 dedrwxrwxr-x 163 juuretöötajad 5,4K 10 komplekt 11:27 man1drwxr-xr-x 11 juurratas 374B 10 komplekt 11:27 man3drwxr-xr- x 7 tagasi staff 238B 10 Set 11:39 man5drwxr-xr-x 11 ago staff 374B 10 Set 11:39 man7-rw-r - r-- 1 root staff 13K 4 Set 11:02 whatis   eel>
Nii on mõeldud Homebrew'i kasutamist. Mõni inimene võib eriarvamusel olla, kuid juhtarendaja ütleb, et tee asju nii.
Veidi parem alternatiiv oma chownile: `sudo chown -R: admin / usr / local`. Nii toimib see sama masina kõigi administraatorikasutajate jaoks. Ehkki peate võib-olla käivitama ka faili `sudo find / usr / local -perm -200 -exec chmod g + w '{}' \ +`, et veenduda, et grupil on kasutajaga sama kirjutusõigus.
"Ma kasutan homebrew'i, see tundub puhtam kui macports. Oh, vaadake seda valesti määratletud lubade segadust. Ma kontrollin Stack Overflow'i. Oh, siin on kiire häkkimine, mis on vastuolus Unixi parimate tavade ja OS-i värskenduste proovimisegatäitmiseks. Täiuslik! ".Kuu hiljem: "Hei, kuidas see pahavara installiti?"
Selle lähenemise probleem on see, et see tähendab, et seda saab kasutada ainult Homebrew'i installinud kasutajakonto.Mul on mitme kontoga Mac, mida kasutan näiteks tööprojektide ja koduprojektide lahus hoidmiseks.Kui olen sisse logitud valele kontole, ei saa ma brew installi kasutada.Ma olen selle tee võtnud, et vältida juurte kasutamise ohte, kuid ma pole veendunud, et see on parim lähenemisviis.
@MikeMcQuaid Minu arvates on huvitav, et Homebrew tunnistas selles lõpuks viga ja on nädal või kaks tagasi välja antud uues versioonis taastanud vaikeload saidile / usr / local
@Agos Vt ülaltoodud kommentaari
Seitse vastused:
#1
+52
Carmine Paolino
2010-09-10 15:47:29 UTC
view on stackexchange narkive permalink

Kasutan ka Homebrew'i ja võin kinnitada, et see on täiesti ohutu. Tsiteerides installimise lehte ametlikus Homebrew'i KKK-s:

Tehke endale teene ja valige / usr / local

  1. See on lihtsam
    / usr / local / bin on juba teie PATH .

  2. See on lihtsam
    Tonni järk-järgulisi skripte puruneb, kui nende sõltuvus pole / usr või / usr / local. Parandame selle Homebrew'i valemite jaoks (kuigi me ei testi seda alati), kuid leiate, et paljud RubyGemsi ja Pythoni seadistuskriptid purunevad, mis on midagi, mida me ei saa kontrollida.

  3. See on ohutu
    Apple on vastanud POSIX-ile ja jätnud selle kataloogi meile. Mis tähendab, et vaikimisi pole kataloogi / usr / local , nii et pole vaja muretseda olemasolevate tööriistade segamise pärast.

Kui plaanite installida pruulidest sõltuvad kalliskivid, siis hoidke endal hunnik vaeva ja installige kataloogi / usr / local !

Pole tühine öelda kalliskivile, et see otsiks ebastandardseid päiste ja düüblite kataloogid. Kui valite / usr / local , siis kõik lihtsalt töötab!

Lisan lihtsalt, et juurte tegemine on väga halb mõte , nii et chown ing / usr / local ei tundu mulle mitte ainult mõistlik (see pole OSX-i jaoks mõeldud süsteem), vaid terve mõistusega .

Teie õigused pole veel õiged. Käivitage lihtsalt loetletud käsk ja kõik saab korda.

Kui teil on muid probleeme, pidage meeles, et pruulimisarst aitab teid!

Kommentaarid pole pikendatud arutelu jaoks;see vestlus on [vestlusesse teisaldatud] (http://chat.stackexchange.com/rooms/31567/discussion-on-answer-by-carmine-paolino-are-my-permissions-for-usr-local-corre).
Vestlus on kadunud, millest on kahju.Seega jätan ajaloo kordamise ohtu oma kommentaari siia: see, et see on tehtud, ei tähenda, et see oleks ohutu.
Diagrammi põhisisu seisneb selles, et Homebrew väidab just seda, et see on vale põhjus
`pruuliarst` on lihtsalt vinge.
@Carmine Paolino Mulle tundub huvitav, et Homebrew tunnistas selles lõpuks viga ja on nädal või kaks tagasi välja antud uues versioonis taastanud vaikeload saidile / usr / local
#2
+37
mmmmmm
2010-09-10 15:50:57 UTC
view on stackexchange narkive permalink

Tavaliselt on parem hoida õigused võimalikult ranged. Kui / usr / local hoiab root omandis, tähendab see, et ainult protsessid, mis töötavad kui root / sudo (või küsige administraatori kasutaja Apple'i autoriseerimise dialoogiboksi kaudu) saab sellesse piirkonda kirjutada. Seega peab protsesside allalaadimine enne failide rikkumist seal parooli küsima.

Kuid nagu te ütlete, muudab see uute programmide lisamise keerulisemaks.

Mul on sudo , kuna installite asju harvemini kui nende käitamist, kuid peate usaldama, et koostamisprotsess ei muuda midagi, mida peaks.

Kui soovite sudot vältida, installiksin Homebrew'i ~ / usr / local ja muutke oma rada, manuaalrada jne, et lisada seal olevad kataloogid.

Parem viis on luua teine ​​kasutaja - öelge näiteks homebrew ja looge sellele kasutajale kuuluv kataloog. Seejärel installige sinna sudo -U homebrew . Teistel kasutajatel on see eelis, et nad ei saa ühtegi teist faili üle kirjutada, kuna need ei tööta nagu root ja muud programmid ei saa homebrew'i mõjutada. (Pange tähele, et Homebrew KKK soovitab seda uut kasutajat, kui olete "mitme kasutaja keskkonnas". Ma ütleksin, et mis tahes Unixi masin, sealhulgas macOS, on mitme kasutaja keskkond)

Kuid nagu Homebrewi wiki ütleb, ei leia retseptid kõiki / usr / local juhtumeid ja asendab need valitud kataloogiga. Ma arvan, et oleme kinni / usr / local kood>.

+1 autoriseerimiste rangena hoidmise ning kasutajate kataloogide lisamise funktsioonide "$ PATH" ja "$ MANPATH" muutmise jaoks. Kui installitud programmid ei vaja kogu süsteemi installimist, on see palju parem alternatiiv.
+1 ja aktsepteeritud vastus "hoidke load võimalikult ranged". "Õllepruulimise" tegemine (soovitatud allpool) ütles mulle, et pean jagama ainult jagatud meeste katalooge ... minu jaoks piisavalt turvaline.
Kompromisslahendus, vähemalt inimestele, kes hoolitsevad piisavalt turvalisuse eest, et mitte pidevalt administraatori kasutajatena töötada, on grupi omaniku ja lubade muutmine, nii et ainult administraatorid saavad kirjutada aadressile / usr / local.Vt kenorbi vastust.
@Mark Minu arvates on huvitav, et Homebrew tunnistas selles lõpuks viga ja on nädal või kaks tagasi välja antud uues versioonis taastanud vaikeload saidile / usr / local
#3
+9
kenorb
2015-05-30 15:09:19 UTC
view on stackexchange narkive permalink

Kui kasutate Homebrew'i, peaksite kirjutamisõiguse andma konkreetsele rühmale (kas admin või personal ), et faile saaks jagada kasutajate vahel, kes on selles rühmas.

Näiteks:

  sudo chgrp -R admin / usr / local / Library / Caches / Homebrewsudo chmod -R g + w / usr / local / Library / Cache / Homebrew  

Seejärel määrake selle rühma kasutajad, kellel peaks olema juurdepääs käsule brew (kontrollige oma rühmi: id -Gn ).

Kui töötate brew -ga, siis ärge käivitage seda funktsiooniga sudo.

Kui teil on veel luba, käivitage probleemi tõrkeotsinguks brew doctor .

+1 tegeliku, paremini käituva-ish lahenduse andmise eest, isegi kui see pole tegelikult lõpule jõudnud.Näiteks: lisada kasutaja BSD-taseme administraatorirühma?Kas see ei sekku OS X Administraatorite kontseptsiooniga?
Salvestamiseks järgisin neid juhiseid, kuid kasutasin lihtsalt oma olemasolevat OS X-i GUI-ga loodud administraatori kasutajat selle asemel, et kedagi CLI-sse mis tahes rühma lisada.See töötab: selleks, et saaksin pruulimiskäske käivitada, pean kõigepealt tegema `su myAdminUser` ja seejärel töötab kõik nii, nagu ette nähtud.Kuid loomulikult ei anna see lahendus mingit turvalisust inimestele, kes niikuinii juba kogu aeg administraatorit kasutavad.
See on ilmselt parim viis minna, nõustun @kenorb-ga
#4
+7
Adam Vandenberg
2010-09-10 20:57:27 UTC
view on stackexchange narkive permalink

Väärtuse mõttes ei pea / usr / local OS X "süsteemi" kaustaks ja uhiuue Snow Leopardi installimisel on see kaust tühi.

Kõik selle kausta juurtele kuuluvad asjad on tulemuseks sudo make install muusse tarkvarasse või parooli andmisele pärast topeltklõpsamist .pkg -il, mis soovib tühjendamist kraam /usr/local.

/ usr / local omamine on "töötanud minu jaoks" kahes masinas üle aasta.

Üks näpunäide on see, et kui olete installinud MySQL-i (mitte Homebrew-d) ja selle failid, siis ilmselt ei näe see enam oma andmebaase (nii et peaksite need tagasi igale kasutajale tagasi laduma) MySQL töötab kui.)

gcc ja muud arendustööriistad vaatavad automaatselt sisse / usr / local, nii et see mõjutab süsteemi
Probleem pole selles, et see oleks "süsteemi" kaust; see on see, et see on "kogu süsteemi hõlmav" kaust. Isegi kui seal pole midagi, on "/ usr / local / bin" endiselt vaikeväärtuses "$ PATH" ja kõike, mida sinna panete, saavad kasutada ka teised kasutajad ja see peaks olema _usaldusväärne_. Kui kogu kataloogil / / usr / local / `on samad õigused, mis praegu OP seadistustel on / usr / local / share / man, võivad kõik minna ja muuta mis tahes binaarset skripti, mis teeb faili` rm -rf ~ `.
liiga riskantne: tõenäoliselt installin MySQL-i varem või hiljem
@Agos: saate MySQL-i alati installida ka HomeBrew'ga, sel juhul pole teil probleeme :)
@CarminePaolino Pole hea mõte. Tavaliselt käituvad Maci installijad, nagu MySql, paremini kui isegi väga hea paketihaldur nagu Homebrew.
@Agos Pole üldse riskantne. Ettevaatus kehtib ainult siis, kui olete MySQL-i installinud enne Homebrew'i. Kui teete seda hiljem, peaksid faili "/ usr / local" õigused olema korras. (Aga arvatavasti kasutate Postgresi ikkagi. :))
#5
+6
Yuhao Zhang
2016-09-21 22:55:56 UTC
view on stackexchange narkive permalink

Nagu Homebrew 1.0.0-s:

Homebrew ei pea enam omama domeeni / usr / local.Kui soovid Saate taastada / usr / local oma vaikeväärtusesse: juur: ratas / usr / kohalik

Värskendan praegu Brew'i, kasutades selleks pruulimisvärskendust, mis nõuab endiselt `/ usr / local` omamist.Proovin õigused pärast seda taastada.
See on tõesti suurepärane info!Ma seadsin peremeesid vastavalt Homebrew (<1.0) määratlusele ja pärast värskendamist andis see need juhised, kuidas neid tagasi seada.
#6
+1
Matias
2020-02-10 02:10:57 UTC
view on stackexchange narkive permalink

MacOS High Sierra versioonis või uuemas versioonis / usr / local ei saa enam chownd.

Homebrew'i meeskond soovitab nüüd: Homebrew'i lubade parandamiseks sudo chown -R $ (whoami) $ (brew --prefix) / * .

Vaadake @Carmine Paolino vastust, et saada lisateavet selle kohta, miks Homebrew soovitab Homebrew'i kataloogide omanikuks saada.

#7
  0
Marnen Laibow-Koser
2013-05-29 21:42:29 UTC
view on stackexchange narkive permalink

Ma arvan, et kasutajate jaoks on kirjutamisõigused / usr / local jaoks OK - lõppude lõpuks tähendab see, et te ei kasuta sudo kood> igal ehituskriptil. Mulle ei meeldi idee, et tavakasutaja omab / usr / local . Eelistaksin, et juur (või muu sarnane) omaks oma / usr / local , kuid muutke õigusi, et kasutajad (või vähemalt mõni privilegeeritud rühm) saaksid sellele kirjutada. See näib olevat kontseptuaalselt õige lähenemine.

Siin on probleemiks see, et "/ usr / local / bin" võib enamuse kasutajate jaoks olla $ PATHi esiküljel. Kataloogi maailmas kirjutatavaks muutmine avab sel moel palju turvaauke.
@patrix Nii et muutke radu. :) Kui teil on skripte, millel on mitmetähenduslike käsuteede tõttu turvaaugud, süüdistaksin ma skripte, mitte teie õigusi - skriptides kutsutud käsud peaksid tavaliselt olema sel põhjusel täielikult kvalifitseeritud. Igatahes pole paremat lahendust: kas annate oma administraatorikontole ebaturvalise umask'i või käivitate kõik oma ehituskriptid `sudo`ga või annate mõnele kasutajale kirjutamisõiguse saidile` / usr / local`. Ma pean kolmandat kõige vähem riskantseks ... kui te ei tea paremat viisi.
Hmm. Mõeldes sellele veel, oleks ehk parem viis lasta Homebrew'l teha seda, mida RVM vaikimisi teeb: installida kõik `~ / brew 'või mõnda muud sellesse. Probleem on aga selles, et erinevalt üsna iseseisva Ruby'st loodavad paljud * nixi utiliidid leida teineteist kataloogist "/ usr / local" ...
Jätsin mainimata, et minu "/ usr / local" pole kirjutatav maailmas: pigem on mul usaldusväärne rühm "homebrew" (mitte ainult admin), kellel on sellele kirjutamisõigused (laiendatud õigused, näiteks "0: group: homebrew lubab add_file, delete, add_subdirectory, delete_child, file_inherit, directory_hernit` täiesti rock). See on parim kompromiss, mille olen suutnud välja mõelda: ehituskriptidel pole "sudo", kuid * mõned kontrollivad seadet "/ usr / local".
@MarnenLaibow-Koser Tahaksin näha selle lähenemise põhjalikumat selgitust (usaldusväärse kasutajate rühma loomine, kellel on kirjutamisõigused saidile "/ usr / local").Palju traaleerimist SO-l ja muudel saitidel, nähes argumente: Homebrew'i viimine kasutaja kodukataloogi vs "/ usr / local" hoidmine, omaniku ja / või grupi "/ usr / local" muutmine või mitte, janii edasi ... on raske öelda, kas on olemas mõni üldtunnustatud lahendus.Kas teil on selle kohta mõni blogipostitus või artikkel või võiksite kusagil sügavama selgituse anda?
@GabrielL.taandub sellele, kas teil on rohkem kui üks kasutaja (ja ka minu vastus), kui jah, siis kumb kasutaja peaks omama / usr / local
@GabrielL.Mis osa sa aru ei saa?Kui saate aru, kuidas * nixi õigused töötavad, ja mõtlete, kes peaks saama kirjutada aadressile `/ usr / local`, peaks seadistamine olema enesestmõistetav.
@MarnenLaibow-Koser - aitäh vastuse eest.Asi pole selles, et ma sellest aru ei saaks, niipalju kui ma ei tea seda, mida ma ei tea.;-) Enamasti püüdsin eristada, millised võivad olla selle lähenemise potentsiaalsed miinused / varjuküljed.See näib olevat hea kompromiss.
@GabrielL.Homebrew soovitab oma KKK-s seda võimalust, kuid "mitmekülgse keskkonna" jaoks
@Marnen: peaksime arvestama, et kuna Catalina / usr / local on püsilink, ei saa te selle jaoks ACL-i luua.Nii et peate seda tegema alamkataloogide jaoks.Proovisin just seda ja see töötab: / usr / local / bin on root: wheel, kuid grupi _brew ACL lubab juurdepääsu.Kuid ka teie enda konto peab olema selle grupi liige.Ja siis saab iga teie kasutajana töötav protsess ikkagi nendesse alamkataloogidesse kirjutada ilma juurõigusteta.Vajame viisi, kuidas see toimima panna * ilma oma gruppi oma kasutajat lisamata.Kas on võimalik oma kasutaja vahetada gruppi, kuhu ta ei kuulu?
Ei ... lööge see viimane küsimus: kui lisate oma kasutaja gruppi _brew, jääte endiselt töötajateks (20).Siis ütleb `pruuliarst` teile, et / usr / local / bin pole kirjutatav.Kui lülitute grupile _brew "newgrp brew" abil, siis "brew doctor" ei märgi / usr / local / bin.Nii et see on tegelikult üsna korralik lahendus.
PS ei, näib olevat töötanud ainult algses Terminalli sessioonis.Pärast uut sisselogimist aktsepteeritakse _brew gruppi, 501 ja _brew on "abielus" ja te ei pea gruppe vahetama, et kirjutada kataloogi / usr / local / bin ... nii et selle lähenemisviisiga pole täiendavat turvalisust.Nii et esialgne küsimus püsib endiselt: kas on võimalik kasutaja vahetada gruppi, mille liige ta pole?
@JayB Võite kasutaja lisada mis tahes gruppi, mis teile meeldib.


See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 2.0-litsentsi eest, mille all seda levitatakse.
Loading...