Kysymys:
Ovatko tiedostoni / usr / local / oikeuteni oikeita?
Agos
2010-09-10 15:07:37 UTC
view on stackexchange narkive permalink

Käytän HomeBrewia porttitarpeitani (näyttää hieman "puhtaammalta" kuin MacPorts).

Voin asentaa ilman sudo ingia (mikä on hienoa), mutta ihmisen linkitysvaihe näyttää vaativan sitä ( / usr / local / share / man / man3 omistaa root ).
Löydetty opas ehdottaa rekursiivisesti chown / usr / local tekemällä

  sudo chown -R `whoami` / usr / local  

Onko tämä turvallista ... vai onko se huono idea?

Lisäksi: ovatko oikeuteni oikein?

  $ pwd / usr / local / share / man $ ls -lahtotal 32drwxrwxr-x 8 päähenkilöstö 272B 4 Aseta 11:02 .drwxrwxr-x 9 päähenkilöstö 306B 10 Sarja 11:27 ..drwxr-xr-x 3 juuripyörä 102B 4 päivää sitten dedrwxrwxr-x 163 juurihenkilöstö 5,4K 10 sarja 11:27 man1drwxr-xr-x 11 juuripyörä 374B 10 Sarja 11:27 man3drwxr-xr- x 7 sitten 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  
Näin Homebrew on tarkoitettu käytettäväksi. Jotkut ihmiset saattavat olla eri mieltä, mutta pääkehittäjä sanoo tekevänsä asioita tällä tavalla.
Hieman parempi vaihtoehto chownillesi: `sudo chown -R: admin / usr / local`. Näin se toimii samalla tavalla kaikille koneen järjestelmänvalvojan käyttäjille. Vaikka saatat joutua suorittamaan myös `sudo find / usr / local -perm -200 -exec chmod g + w '{}' \ +`, varmistaaksesi, että ryhmällä on samat kirjoitusoikeudet kuin käyttäjällä.
"Käytän homebrew'ta, se tuntuu puhtaammalta kuin macports. Voi, katso tätä epämääräistä lupamessua. Tarkastan Stack Overflow -palveluun. Oh, tässä on nopea hakkerointi, joka on ristiriidassa Unixin parhaiden käytäntöjen ja käyttöjärjestelmän päivitysten kanssaTäydellinen! ".Kuukausi myöhemmin: "Hei, miten tämä haittaohjelma asennettiin?"
Tämän lähestymistavan ongelmana on, että se tarkoittaa, että vain Homebrewn asentava käyttäjätili voi käyttää sitä.Minulla on Mac, jolla on useita tilejä ja jota käytän pitämään työprojektit erillään esimerkiksi kotiprojekteista.Jos olen kirjautunut väärälle tilille, en voi käyttää panimoasennusta.Olen valinnut tämän reitin välttääksesi juurien käytön vaarat, mutta en ole vakuuttunut siitä, että se on paras tapa.
@MikeMcQuaid Minusta on mielenkiintoista, että Homebrew on vihdoin myöntänyt vian tässä ja viikossa tai kaksi sitten julkaistussa uudessa versiossa palauttanut oletusoikeudet tiedostoon / usr / local
@Agos Katso yllä oleva kommentti
Seitsemän vastused:
#1
+52
Carmine Paolino
2010-09-10 15:47:29 UTC
view on stackexchange narkive permalink

Käytän myös Homebrew'ta ja voin vahvistaa, että se on täysin turvallista. Lainaten Asennus -sivua virallisessa Homebrew FAQ: ssä:

Tee itsellesi palvelus ja valitse / usr / local

  1. Se on helpompaa
    / usr / local / bin on jo PATH-koodissasi .

  2. Se on helpompaa
    Tonnia koontikomentosarjoja hajoaa, jos niiden riippuvuudet eivät ole / usr tai / usr / local. Korjaamme tämän Homebrew-kaavoille (vaikka emme aina testaa sitä), mutta huomaat, että monet RubyGems- ja Python-asennusohjelmat hajoavat, mikä on meidän hallinnan ulkopuolella.

  3. Se on turvallista
    Apple on noudattanut POSIX-järjestelmää ja jättänyt tämän hakemiston meille. Tämä tarkoittaa, että oletuksena ei ole hakemistoa / usr / local , joten sinun ei tarvitse huolehtia olemassa olevien työkalujen sekoittamisesta.

Jos aiot asentaa hautumisesta riippuvia helmiä, säästä sitten itsellesi joukko vaivaa ja asenna osoitteeseen / usr / local !

Ei ole triviaalia sanoa jalokiville etsimään epätyypillisiä hakemistot otsikoille ja dylibeille. Jos valitset / usr / local , kaikki “vain toimii!”

Lisään vain, että asioiden tekeminen juurina on erittäin huono idea , joten chown ing / usr / local ei pelkästään näytä minulle järkevältä (se ei ole OSX: n järjestelmäohjaus), mutta järkevä .

Käyttöoikeutesi eivät ole oikein (vielä). Suorita vain luetteloima komento ja olet kunnossa.

Jos sinulla on muita ongelmia, muista, että panimolääkäri voi auttaa sinua!

Kommentteja ei käytetä laajempaan keskusteluun;tämä keskustelu on siirretty chattiin (http://chat.stackexchange.com/rooms/31567/discussion-on-answer-by-carmine-paolino-are-my-permissions-for-usr-local-corre).
Keskustelu on poissa, mikä on sääli.Joten riskin toistaa historia, jätän kommenttini tähän: se, että tämä tehdään, ei tarkoita, että tämä on turvallista.
Kaavion ydin on, vaikka Homebrew ehdottaa, että tämä on väärin, on olemassa syitä
`panimolääkäri` on yksinkertaisesti mahtavaa.
@Carmine Paolino Minusta on mielenkiintoista, että Homebrew on vihdoin myöntänyt vian tässä ja viikossa tai kaksi sitten julkaistussa uudessa versiossa palauttanut oletusoikeudet tiedostoon / usr / local
#2
+37
mmmmmm
2010-09-10 15:50:57 UTC
view on stackexchange narkive permalink

On yleensä parempi pitää käyttöoikeudet mahdollisimman tiukoina. / usr / local : n pitäminen root : n omistuksessa tarkoittaa, että vain prosessit, jotka suoritetaan nimellä root / sudo (tai pyydä järjestelmänvalvojan käyttäjä Applen valtuutusvalintaikkunan kautta) voi kirjoittaa tälle alueelle. Siksi prosessin lataamisen on pyydettävä sinulta salasana ennen tiedostojen vioittamista siellä.

Mutta kuten sanot, se vaikeuttaa uusien ohjelmien lisäämistä.

Olen kunnossa suorittamalla sudo , koska asennat asioita harvemmin kuin suoritat niitä, mutta sinun on luotettava siihen, että rakennusprosessi ei muuta mitään sen pitäisi.

Jos haluat välttää sudoa, asennan Homebrew-sovelluksen ~ / usr / local ja muuta polkua, manpath jne. sisällyttääksesi hakemistot siellä.

Parempi tapa on luoda toinen käyttäjä - sanoa homebrew ja luoda kyseisen käyttäjän omistama hakemisto. Asenna sitten sinne käyttämällä sudo -U homebrew . Muut käyttäjät hyötyvät siitä, että he eivät pysty korvaamaan muita tiedostoja, koska ne eivät ole käynnissä, koska root ja muut ohjelmat eivät voi vaikuttaa homebrew-tiedostoon. (Huomaa, että Homebrew-usein kysytyt kysymykset ehdottaa tätä uutta käyttäjää, jos olet "monen käyttäjän ympäristössä". Sanoisin, että mikä tahansa Unix-kone, mukaan lukien macOS, on monen käyttäjän ympäristö)

Kuitenkin kuten Homebrew-wiki sanoo, reseptit eivät löydä kaikkia / usr / local -tapauksia ja korvaavat ne valitulla hakemistolla. Epäilen, että olemme jumissa / usr / local koodi>.

+1, kun pidät valtuutuksia tiukkana ja muutat "$ PATH" ja "$ MANPATH" sisällyttämään käyttäjähakemistoja. Jos asennetut ohjelmat eivät vaadi koko järjestelmän asentamista, se on paljon parempi vaihtoehto.
+1 ja hyväksytty vastaus "pidä käyttöoikeudet mahdollisimman tiukkana". `` Panimolääkärin`` tekeminen (ehdotettu alla) kertoi minulle, että minun täytyy vain hakea jaettujen miesten hakemistoja ... riittävän turvallinen minulle.
Ainakin ihmisille, jotka huolehtivat riittävästi tietoturvasta, jotta he eivät pääse jatkuvasti järjestelmänvalvojan käyttäjiksi, kompromissiratkaisu on muuttaa ryhmän omistajaa ja käyttöoikeuksia, jotta vain järjestelmänvalvojat voivat kirjoittaa osoitteeseen / usr / local.Katso kenorbin vastaus.
@Mark Minusta on mielenkiintoista, että Homebrew on vihdoin myöntänyt vian tässä ja viikossa tai kaksi sitten julkaistussa uudessa versiossa palauttanut oletusoikeudet tiedostoon / usr / local
#3
+9
kenorb
2015-05-30 15:09:19 UTC
view on stackexchange narkive permalink

Jos käytät Homebrew-versiota, sinun on annettava kirjoitusoikeus tietylle ryhmälle (joko admin tai staff ), jotta tiedostot voidaan jakaa käyttäjien välillä, jotka ovat kyseisessä ryhmässä.

Esimerkiksi:

  sudo chgrp -R admin / usr / local / Library / Caches / Homebrewsudo chmod -R g + w / usr / local / Kirjasto / välimuistit / Homebrew  

Määritä sitten käyttäjät, joilla pitäisi olla pääsy brew -komentoon, kyseiseen ryhmään (tarkista ryhmät: id -Gn ).

Jos työskentelet brew -työkalun kanssa, älä suorita sitä sudo -näytöllä.

Kun sinulla on vielä joitain käyttöoikeusongelma, suorita brew doctor ongelman vianmääritykseen.

+1 antaa todellisen, paremmin käyttäytyvän-ish-ratkaisun, vaikka se ei olekaan vielä valmis.Esimerkiksi: lisätäänkö käyttäjä hallintaryhmään BSD-tasolla?Eikö se sotkeudu OS X: n järjestelmänvalvojan käyttäjien käsitteeseen?
Tietueeksi seurasin näitä ohjeita, mutta käytin vain nykyistä OS X -käyttöliittymän tekemää järjestelmänvalvojan käyttäjää sen sijaan, että lisäsin ketään mihin tahansa ryhmään CLI: ssä.Se toimii: voidakseni suorittaa suodatuskomentoja, minun on ensin tehtävä `su myAdminUser`, ja sitten kaikki toimii tarkoitetulla tavalla.Mutta tietysti tämä ratkaisu ei anna mitään turvallisuutta ihmisille, jotka silti käyttävät jo järjestelmänvalvojan käyttäjää koko ajan.
Tämä on luultavasti paras tapa edetä, olen samaa mieltä @kenorb: n kanssa
#4
+7
Adam Vandenberg
2010-09-10 20:57:27 UTC
view on stackexchange narkive permalink

OS X ei pidä / usr / local -koodia sen arvoista, että se on "järjestelmä" -kansio, ja upouudessa Snow Leopard -asennuksessa kyseinen kansio on tyhjä.

Kansion kaikki juuren omistamat asiat ovat seurausta sudo make install -sovelluksesta muulle ohjelmistolle tai salasanasi antamisesta kaksoisnapsauttamalla .pkg -linkkiä, joka haluaa tyhjentää tavaraa /usr/local.

/ usr / local -omistuksen omistaminen on "toiminut minulle" kahdessa koneessa yli vuoden ajan.

Yksi hascha on, että jos olet asentanut MySQL: n (et käytä Homebrew-tiedostoa) ja chown sen tiedostot, se ei todennäköisesti näe enää tietokantojaan (joten sinun on syötettävä ne takaisin kenelle tahansa käyttäjälle MySQL toimii nimellä.)

gcc ja muut kehitystyökalut näyttävät automaattisesti hakemistosta / usr / local, joten se vaikuttaa järjestelmään
Ongelma ei ole, että se on "järjestelmä" -kansio; se on, että se on "järjestelmänlaajuinen" kansio. Vaikka mitään ei olisikaan, `/ usr / local / bin` on edelleen oletusarvossa` $ PATH`, ja mitä tahansa sinäkin kirjoitat, sitä voivat käyttää muutkin käyttäjät, ja sen pitäisi olla _ luotettava_. Jos koko hakemistolla / / usr / local / `on samat käyttöoikeudet kuin tällä hetkellä OP: n asennuksessa, kuka tahansa voi mennä vaihtamaan mitä tahansa binääriä komentosarjalla, joka tekee` rm -rf ~ `.
liian riskialtista: on todennäköistä, että asennan MySQL: n ennemmin tai myöhemmin
@Agos:: n avulla voit aina asentaa MySQL: n HomeBrew: n kanssa, jolloin sinulla ei ole ongelmia :)
@CarminePaolino Ei hieno idea. Yleensä Mac-asentajat, kuten MySql tarjoaa, käyttäytyvät paremmin kuin edes erittäin hyvä paketinhallinta, kuten Homebrew.
@Agos Ei lainkaan riskialtista. Varoitus pätee vain, jos olet asentanut MySQL: n ennen Homebrew-sovellusta. Jos teet sen jälkeenpäin, tiedoston "/ usr / local" käyttöoikeuksien pitäisi olla kunnossa. (Mutta luultavasti käytät Postgresia joka tapauksessa. :))
#5
+6
Yuhao Zhang
2016-09-21 22:55:56 UTC
view on stackexchange narkive permalink

Kuten Homebrew 1.0.0:

Homebrew ei enää tarvitse omistaa / usr / local.Jos haluat Voit palauttaa / usr / local sen oletusominaisuuteen: sudo chown juuri: pyörä / usr / paikallinen

Päivitän tällä hetkellä Brewia käyttämällä `` brew update '', joka vaatii edelleen `/ usr / local` -omistuksen.Yritän palauttaa käyttöoikeudet jälkikäteen.
Tämä on todella upeaa tietoa!Asetin perbemejä Homebrewin määrittelemällä tavalla (<1.0), ja päivityksen jälkeen se antoi nämä ohjeet niiden asettamiseen takaisin.
#6
+1
Matias
2020-02-10 02:10:57 UTC
view on stackexchange narkive permalink

MacOS High Sierrassa tai uudemmassa versiossa / usr / local ei voi enää seurata.

Homebrew-tiimi suosittelee nyt: sudo chown -R $ (whoami) $ (brew --prefix) / * Homebrew-käyttöoikeuksien korjaamiseksi.

Katso @Carmine Paolinon vastauksesta saadaksesi lisätietoja siitä, miksi Homebrew suosittelee Homebrew-hakemistojen omistamista.

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

Mielestäni on hyvä, että käyttäjillä on kirjoitusoikeudet kohteeseen / usr / local - loppujen lopuksi se tarkoittaa, että et käytä sudo jokaisessa koontikomentosarjassa. En pidä ajatuksesta, että tavallinen käyttäjä omistaa / usr / local . Haluaisin mieluummin juuri (tai vastaavan) oman / usr / local -ominaisuuden, mutta vaihda käyttöoikeudet, jotta käyttäjät (tai ainakin jotkut etuoikeutetut ryhmät) voivat kirjoittaa siihen. Se näyttää olevan käsitteellisesti oikea lähestymistapa.

Ongelmana on, että `/ usr / local / bin` voi hyvinkin olla $ PATH: n etupuolella useimmille käyttäjille. Hakemiston tekeminen maailman kirjoitettavaksi avaa tällä tavoin paljon suojausreikiä.
@patrix Vaihda siis polkuja. :) Jos sinulla on komentosarjoja, joissa on tietoturva-aukkoja epäselvien komentopolkujen takia, syyttäisin komentosarjoja, ei oikeuksiasi - komentosarjoissa käytettyjen komentojen tulisi yleensä olla täysin päteviä juuri tästä syystä. Joka tapauksessa, ei ole parempaa ratkaisua: joko annat järjestelmänvalvojan tilillesi epävarman umaskin, tai suoritat kaikki rakennuskomentosi `sudo`: lla tai annat joillekin käyttäjille kirjoitusoikeudet osoitteeseen` / usr / local`. Katson kolmannen olevan vähiten riskialtista ... ellet tiedä parempaa tapaa.
Hmm. Ajattelemalla tätä vielä enemmän, ehkä parempi tapa olisi saada Homebrew tekemään se, mitä RVM tekee oletusarvoisesti: asentamaan kaikki `` ~ / brew '' -ohjelmaan tai vastaavaan. Ongelmana on kuitenkin se, että toisin kuin Ruby, joka on melko itsenäinen, monet * nix-apuohjelmat odottavat löytävänsä toisensa hakemistosta `/ usr / local``.
Laiminlyöin mainita, että `/ usr / local` ei ole kirjoitettavissa maailmanlaajuisesti: minulla on pikemminkin luotettu ryhmä` `homebrew` '(ei vain admin), jolla on kirjoitusoikeudet siihen (laajennetut oikeudet, kuten` `0: group: homebrew salli add_file, delete, add_subdirectory, delete_child, file_inherit, directory_inherit` täysin rock). Tämä on paras kompromissi, jonka olen pystynyt selvittämään: ei "sudoa" rakentaa skriptejä, mutta * jotkut * hallitsevat tiedostoa "/ usr / local".
@MarnenLaibow-Koser Haluaisin nähdä syvällisemmän selityksen tästä lähestymistavasta (luotavan luotettavan käyttäjäryhmän, jolla on kirjoitusoikeudet osoitteeseen "/ usr / local").Paljon troolaamista SO: lla ja muilla sivustoilla, näkemällä argumentit uudelleen: Homebrew'n siirtäminen käyttäjän kotikansioon verrattuna pitämiseen `/ usr / local` -palvelussa, omistajan ja / tai ryhmän / / usr / local` vaihtaminen vai ei, janiin edelleen ... on vaikea sanoa onko olemassa yleisesti hyväksyttävää ratkaisua.Onko sinulla blogiviesti tai artikkeli tästä, vai voisitko antaa syvemmän selityksen jossakin?
@GabrielL.päättyy, onko sinulla useampi kuin yksi käyttäjä (ja myös vastaukseni), jos on, kumman käyttäjän tulisi omistaa / usr / local
@GabrielL.Mitä osaa et ymmärrä?Jos ymmärrät * nix-käyttöoikeuksien toiminnan ja ajattelet, kenen pitäisi pystyä kirjoittamaan osoitteeseen `/ usr / local`, asennuksen tulisi olla itsestään selvää.
@MarnenLaibow-Koser - kiitos vastauksesta.Se ei ole, että en ymmärrä sitä, niin paljon kuin en tiedä mitä en tiedä.;-) Enimmäkseen yritin erottaa, mitkä ovat tämän lähestymistavan mahdolliset haitat / haittapuolet.Se näyttää hyvältä kompromissilta.
@GabrielL.Homebrew ehdottaa tätä tapaa usein kysytyissä kysymyksissään, mutta "moniympäristölle"
@Marnen: on huomattava, että koska Catalina / usr / local on kiinteä linkki, joten et voi luoda sille ACL: ää.Joten sinun on tehtävä se alihakemistoille.Yritin juuri sitä, ja se toimii: / usr / local / bin on root: wheel, mutta ryhmän _brew ACL sallii pääsyn.Oman tilisi on kuitenkin oltava myös kyseisen ryhmän jäsen.Ja sitten jokainen käyttäjänäsi käynnissä oleva prosessi voi silti kirjoittaa näihin alihakemistoihin ilman pääkäyttöoikeuksia.Tarvitsemme tapan saada se toimimaan * lisäämättä omaa käyttäjää ryhmään.Onko mahdollista vaihtaa käyttäjä ryhmään, johon se ei kuulu?
Ei… lakko viimeiseen kysymykseen: jos lisäät käyttäjän _brew-ryhmään, pysyt silti henkilöstössä (20).Sitten `panimolääkäri` kertoo sinulle, että / usr / local / bin ei ole kirjoitettavissa.Jos vaihdat ryhmään _hautua "newgrp brew": lla, "brew doctor" ei ilmoita / usr / local / bin.Joten tämä on oikeastaan melko kunnollinen ratkaisu.
PS ei, näyttää toimineen vain alkuperäisessä Terminall-istunnossa.Uuden kirjautumisen jälkeen _brew-ryhmä hyväksytään, 501 ja _brew ovat "naimisissa", eikä sinun tarvitse vaihtaa ryhmiä kirjoittaaksesi osoitteeseen / usr / local / bin ... joten ei lisättyä suojausta tällä lähestymistavalla.Joten alkuperäinen kysymys on edelleen voimassa: Onko mahdollista vaihtaa käyttäjä ryhmään, jonka jäsen se ei ole?
@JayB Voit lisätä käyttäjän mihin tahansa haluamaasi ryhmään.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 2.0-lisenssistä, jolla sitä jaetaan.
Loading...