systemd bug - számmal kezdődő felhasználónév esetén rootként indul a unit file

A címben a lényeg: amennyiben egy systemd unit file-ban a "user" mező értéke számmal kezdődik, a megadott user helyett root jogosultsággal fut le az adott unit file.

Miért?
Mert a systemd a user mező ellenőrzésekor formailag hibásnak tekinti a számmal kezdődő felhasználóneveket, ezért az alapértelmezett felhasználóval futtatja az adott unit file-t, ami pedig a root.

Miért baj ez?
Mert pl. CentOS/RH rendszeren teljesen elfogadott a számmal kezdődő felhasználónév.

Ez a bug kiváló példa két dologra: egyrészt fejlesztőként nem lehet burokban élni, nem gondolva más rendszerekre, másrészt arra, hogy érdemes átgondolni milyen alapértelmezett értékeket helyettesítünk be ott ahol az adott mezőt nem találjuk helyesnek...

Forrás: bugreport, blogpost

Hozzászólások

Poettering szerint ez nem bug, hanem feature. És szerinte a 0day név amúgy is invalid és pont. A hibajegyet meg lezárták, nem javítják, pedig az egyik user még meg is jegyezte, hogy akár invalid, akár nem, nem a root-ra kéne revertelni.

A default ExecStart pedig legyen az rm -rf /. Persze szigorúan, mint feature - hiszen ha nincs valid ExecStart, akkor gondoskodik róla, hogy a rendszer kiszámíthatóan viselkedjen!

Meg is lepődtem volna, ha a systemd hibája lenne... Még mit nem!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Banyek! Most már értem a poén hátterét, amit reggel a wc-n olvastam twitteren.

Valami olyasmivel volt a poénkodás, hogy a pottering-et mint igét használták.
A pontos szövegre nem emlékszek de a lények kb.: ostoba balfasz vagy, nyilvánvaló hibát elkövetsz, és erre a reakciód tagadás és a mindenki hülye csak én vagyok helikopter mentalitás.

Nem lehet, hogy a systemd igazából csak egy grandiózus szocio-kultúrális kísérlet az informatikai társadalom tűrőképességének a tanulmányozására? És pottering mögött egy iszonyú dörzsölt antropológus troll húzódik meg, és egy szakértői csapat animálja a kongresszusokon?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Van erre több népszerű konteó is. :)

1. A kernelbe nehéz lenne backdoort tenni, mert túl sokan látják, nem hülyék (nem minden téren) és Linus nem fogja merge-ölni a saját Git fájába. Bár az utóbbi időben amilyen security track recordja van a Linuxnak, erre nem is kéne nagyon rágyúrni. Lásd a csörtét a Grsecurityval szemben, amikor azok tetemre hívták Linust és a KSPP "fejlesztőit" is.

2. Ha a kernelbe nem lehet backdoort rakni, a következő logikus pont a PID 1, mert az mindenbe belelát. Tehát az egyszerű, megbízható és bevált init ment és helyette jött a túlbonyolított, átláthatalan és egyre inkább hízó, (biztonsági) lyukakkal teli systemd. Megfejelve egy olyan vezető fejlesztővel, akinek a személyisége is kérdőjeleket vet föl, lásd a "hibakezelési folyamatot". Ezeket összerakod és garantált egy olyan, magas privilégiumokkal futó rendszar (nem typo), ami önmagában sem túl megbízható, de még exploit is könnyen írható hozzá.

Az állandó patchelési igény mellett ez folyamatosan biztosítja a lehetőséget egy-egy obskurusabb bugnál, hogy a t. ügyfél kemény pénzeket letegyen a supportért.

És máris megérkeztünk a Redhat üzleti modelljéhez.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Ezt nem én találtam ki, hanem a neten olvastam. Több, egymástól független forrásban is, szak-site, fórum, vatevör. Szóval nem csak egy embernek tűnt föl.

Személy szerint nem igazán érdekel, hogy a Redhat mit csinál, nem használom otthon semmilyen terméküket, ill. folyományait.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

De mért kell egy invalid fájlt rootal futtatni, ami már amúgy is rossz rontsuk tovább?
Nem lehet egyszerűen egy hibát dobni, lelogolni azt kész?

♲♻♲

Te is csak addig fogod szeretni amíg a dokumentáció alapján beállítasz valamit ami aztán homlokegyenest máshogy fog működni. Jó openszósz userhez méltóan amit aztán jelzel a fejlesztő fele aki közli, hogy WONTFIX és ez így jó ahogy van.
Arról ne is beszéljünk, hogy a jó emberből én azt is kinézem, hogy egy update során elkufircol valamit aminek hatására eltossza a gépet egy addig "jól" működő systemd.

@@
"You can hide a semi truck in 300 lines of C."

P válasza alapján azt gondolom, hogy ez a jóember nagy szolgálatot tehetne a Unixos világnak. Ha pl. Windows-ra fejlesztene.

Nem hallott a strtol-ról, hanem az isdigit-tel ellenőrizte, hogy numerikus-e, ez még hagyján, az ember feje nem káptalan. De amikor kimutatják a hibát, akkor azért beleférne egy 'hoppá, bocsika', a 'not my fault' helyett.

hat azon dolgozik, hogy sokan atterjenek valami masra a linuxrol, most hogy a systemd lassan atveszi mindenhol a hatalmat. Kihasznalja azt, amit mar elottem mondott valaki, hogy a nagy disztrok basznak fejleszteni, inkabb hasznalnak valamit ami kiszolgalja oket. A systemd meg ilyen barmilyen szar is legyen.

Szoval jovora en is apple-es leszek asszem. Isten veled Linux. (na jo csak vicceltem, bar elgondolkodtam rajta miota systemd szopas van) :D

Hat nalam aztan tuti nem.
Az otlet viszont tetszett, mivel mar solarist vizionaltam a Linuxbol.
En meg hasznaltam initng-t es orultem egy jobb implementacionak. A celok rendben voltak, de aztan elk@rodott minden.
Szemleltetve: akartunk gyujtani egy kis tuzet az erdoben egy pihenoben, erre jott valaki, hogy na majd o megmutatja hogy lehet ezt jol csinalni es rankgyujtotta az egesz kibeb@szott erdot. Mind meghalunk. :D

Az otlet viszont tetszett, mivel mar solarist vizionaltam a Linuxbol.

Ahhoz annyit kellett volna tenni, hogy az SMF-et valaki portolja (leginkább a hozzá szükséges kernel támogatást kellett volna). De ezeknek a Túlokos Tiboroknak az túl jó lett volna, helyette inkább rácsatlakoztak a szívócsonkra...

Slackware alatt:

man useradd

...
Usernames must start with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular expression terms:
[a-z_][a-z0-9_-]*[$]?
...

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Debian alatt:

It is usually recommended to only use usernames that begin with a lower
case letter or an underscore, followed by lower case letters, digits,
underscores, or dashes. They can end with a dollar sign. In regular
expression terms: [a-z_][a-z0-9_-]*[$]?

Azaz csak javasolt, nem kötelező, tehát nem invalid egy számmal kezdődő név. De amúgy egyfelől a POSIX sem írja elő, hogy ne kezdődhessen számmal a név (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_437), másfelől meg ahogy az egyik user is megjegyezte, akár invalid, akár nem, talán nem a root-ra kéne revertelni hiba esetén.

A Slackware túl öreg már az ilyen modern dolgokhoz. Mondjuk nekem kicsit meglepő volt, amikor kiderült, hogy ezzel a konzervativizmussal együtt is, a gyárilag telepített rendszerben nincs engedélyezve egy vacak getty a COM1: -en.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

1. Én úgy emlékeztem, a Slackware korábbi, mint a Debian. A Wikipedia ebben megerősített. (Slack 1.0 '93. július 17. , Debian 0.01 '93. szept. 15). OK, én nagyobb különbségre emlékeztem, de ettől még öregebb.
2. Én öreget írtam, szerinted pedig annyi idős, mint a Debian. - > Szerintem a Debian is elég öreg (valszeg szerinted meg nem).
3. Az valóban egy lényeges különbség, h Patrick-ék maradtak SysV initnél, míg ugye nem véletlenül lett Devuan.

És amúgy a kérdésre válaszolva:

Szerintem egy szoftverrendszer életében azért 24 év (az egyiknél kicsit több, a másiknál kicsit kevesebb) az már szép kor. Lehet, hogy szerinted meg nem. Ezen nem fogunk összeveszni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"A Slackware túl öreg már az ilyen modern dolgokhoz."

Bocsi, hogy belepofazok, de az en olvasatomban azt irtad, hogy azert nincs benne ez a hiba, mert a Slackware egy regi rendszer (marmint nem mostanaban kezdtek feljeszteni) = elavult / nem modern -> ha valamit regen kezdtek fejleszetni az nem lehet modern. Holott, ez nem attol fugg, hiszen attol meg lehet naprakesz ha rendesen fejlesztik, karbantartjak. Itt irrelevans, hogy van koztuk 24 ev tavlataban par honap a Slackware javara. Szoval az nem feltetlen helyes kovetkeztetes, hogy amit regen kezdtek el, az nem lehet modern. Azert van par rendszer ami nagyon regre nyulik vissza, megis kepes haladni korral, a Windows sem most kezdodott, es bar sokan nem szeretik, azert azt valosinuleg mindenki latja, hogy egy win 10-nek kb. semmi koze egy Win 2.0-hoz a neven meg a gyartojan kivul.

/sza2

> Bocsi, ... de az en olvasatomban

Kiemeltem hozzászólásod érdemi részét.

> Szoval az nem feltetlen helyes kovetkeztetes,

Nyertél, nem volt helyes következtetés tőled.

Nem, nem ezt jelentette. Inkább azt, hogy mostanra már talán kialakult a kisszámű fejlesztőgárdában az általában idősebbek által preferált "lassan járj, tovább é[rl]sz" szemlélet. Esetleg tudják és merik is használni a meglevő eszközöket, és nem akarnak számukra nem létező problémákat megoldani oly módon, hogy 5 perc alatt kidobják a 20 éve létező alapot, és lecserélik egy olyan tákolmányra, amelynek tervezésekor a csillagromboló volt a cél láthatóan.

Ja, és én se akarok systemd-hitvitát, egyszerűen leírtam a véleményemet.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Erről az jutott eszembe, hogy a systemd esetén mi volt a gond az inittab-bal, hogy ne lehetett volna legalább kompatibilitási okokból figyelembe venni?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Majd még megnézem, de emlékeim szerint van a bhyve-om alatt
- egy 1404-ként telepített, majd arról upgrade-elt 1604-es uborka
- egy frissen installált 1604-es uborka
- egy centos7
- egy debian8
- és egy fbsd11
- meg egy salak

Ebből a salak volt az egyetlen, amelyiken küzdeni kellett a COM1-en nem figyelő getty miatt. Úgyhogy akkor ezeket a disztrókat /OS-eket máris meg lehet toszni az önmegsemmisítőddel (még systemd sem kell hozzá, csak hogy legalább félig ontopic legyek.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ha érdekel valakit
Feltettem egy PATA 160-as lemezre a
Devuan 1-et. Ez volt üres.
Egymagos HT-s 3GHz-es processzoron egész jól elfut.
A 32bitest tettem fel, 4G RAM-ra.
Kinézetre szinte teljesen ugyanaz mint az eredeti Jessie.
Teljesen használható, irtó gyors a leállás.
Ami sztem óriási hiba, enged csak root felhasználót létrehozni és azzal be is enged logolni a grafikus felületre.
Rég telepítettem, az erdeti ha jól emlékszem, nem engedni a root logint Xorg-ra.
Vagy igen?

Megkérdezném az okoskákat (de ugye jó szokás szerint már lockolták a threadet), hogy egyáltalán miért root a default, miért nem a nobody user? Miért nem csak explicit User=root esetén futhat _bármi_ rootként?

Bevallom, hogy sok éve nem használtam NFS-t, akkor is no_root_squash-sal, mert root nfs volt. Valóban nem emlékeztem, hogy a nobody-nak lehet NFS kötődése.

Ettől még szerintem kisebb kárt tud tenni, mint a root, illetve ha nem konkrétan "a" nobody, akkor másik kellően bekorlátozott userid-t létre lehet hozni erre a célra. Csak ne root legyen már a default...

Ha valami NFS-en meg van osztva, akkor ott bízol abban, hogy a teljes infrastruktúra a te kezedben van. Csak olyan IP-k felé osztod meg, ahol a user management a kezedben van. Amihez pedig nfs-en nobody is hozzáfér, azt amúgy is publikusnak szántad.

Félreértés ne essék: én is használok / használtam nfs-t. Elég sokat. Abszolút nem kritika az nfs-el szemben. Kifejezetten kedvelem.

A mondandóm lényege: Helyén kell az nfs-t kezelni -> amit felvetsz problémát nem valós.
Ahol ez probléma: ott... mondjuk úgy, erősen gondatlanul járt el a megosztás gazdája, amit csak neki lehet felróni. Punkt.
Btw.: Meg lehet azt is adni nfs szerver oldalon, hogy a "nobody" usereket helyben milyen uid/gid -re mappelje! ;-)

Sok szervíz pl. csak azért root (az elején) mert alacsony portra bindol. Nem lenne jobb, ha már alapból myserviceuid -dal indítanánk, de kapna egy CAP_NET_ADMIN-t, amit majd jólnevelten eldob? Nyilván van olyan eset, amikor ez nem elég, de azokra is szerintem lehetne megoldást találni, hogy ne kelljen root-nak lennie az alapértelmezett indításnak.

Szerintem egyébként egyáltalán nem rossz irány, amit pl. a RancherOS csinál, hogy már a System service-ek is külön konténerben futnak (lehetőleg) minimalizált privilégiumokkal.

Közvetlenül azt se, hogy helyesen váltson át root-ról XYZ uid/gid-re.

De pont a systemd elterjedtsége miatt lenne ereje egy olyan bejelentésnek, hogy a systemd már csak

User=root
Iknowwhatiamdoing=yes,really

esetén hajlandó bármit rootként indítani, egyébként meg mindenki rendesen konfigurálja a capabilty-ket, BPF-et, SELinux-ot, ... stb.-t.

Ahelyett, hogy azt mondják, hogy ez By Design és not a bug

és akkor a másik oldalról jön a sírás, hogy
a) ahogy a systemd csinálja, az szar, én nem akarom használni
b) miért a systemd szarja a spanyolviaszt, és mondja meg mindenkinek, hogy át kell írni a dolgaim, amik már 20 éve jók úgy.

Szóval ezek mindig ilyen if (sapka || !sapka) esetek. Egyébként szerintem az eseten már az is sokat segítene, ha a "nem értem, mi van odaírva, hisztizek, leszarom, azt majd lesz valami" stratégia helyett a "nem értem mi van odaírva, ezt én nem indítom el" lenne az alapértelmezett viselkedés, és akkor nem derülne ki ilyen cornercaseknél, hogy valami nem trivi. (bár ez nyilván ortogonális arra a problémára, hogy a User defaultja a root)

Erre a problémára létezik egy formabontó, meghökkentő megoldás: mi lenne, ha a default viselkedést konfigurációs fájlból lehetne állítani? Bár gyanús, hogy ez egybevágna a Unix filozófiával, úgyhogy kerülendő! A végén még a felhasználó mindenféle módon finomhangolhatná a rendszert a saját kényére-kedvére...
Illetve ha konfigurációs fájlt kéne használni, akkor lehetőleg legyen mind bináris formátumban, hogy sima text editorral ne lehessen szerkeszteni! Pl.: a konfigurációs fájlokat csak a systemd-configd által biztosított interface-szen keresztül lehetne szerkeszteni a systemd-config-editor-ral - illetve elvakultabbaknak ott lenne még a systemd-vi és a systemd-emacs! A config-editor futtatásához wayland vagy mir kell. A konfig értékek pedig a systemd-registry-ben lennének tárolva. Szigorúan sajátos formátumban. Remélem pottering nem tud magyarul, hogy ezt az ötletet elolvassa...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Hat az utobbi 20 evben nekem nem volt gondom a syslogd-vel vagy az rsysloggal, de hat ertem :D

No fijam ehun van egy csillagfeju csavarhuzo, oszt ha sima csavarot akarsz kicsavarozni vele, hat verjed soka a kalapaccsal a fejit laposra. Na ertem?

Kaptok ti penzt azert, hogy Potterunk vegtermeket(ertsd: buzlo sz@r) ajnarozzatok vagy csak a groupie-jai vagytok es az oltozojeben tomboltok? :D

Ja es nem szeretem, ha megmondjak mit gondolok vagy kell gondolnom :D

Egyrészt, attól, hogy személyeskedsz, meg káromkodsz, nem lesz jobban igazad, úgyhogy kérlek.

Másrészt félreérted, én nem mondtam meg neked, hogy mit kell gondolnod, vagy hogy mit gondolsz, pusztán arra a logikai bakugrásra próbáltam felhívni a figyelmedet, hogy a te saját véleményedet "amúgy is jól megy" általános igazságként beállítva röhögsz azon, hogy valami ezt másképp képzeli. Ez meg nyilvánvalóan egy ordas nagy faszság (opardon, f@szság, hogy a stílusodnál maradjunk :) ). Az, hogy neked még nem volt gondod a syslogdvel, az örömteli, használd egészséggel, ettől még nem biztos, hogy a journald másoknak nem jobb (figyelj, még csak azt se mondtam, hogy nekem, egyszerűen csak az érvelési hibádra probálom felhívni a figyelmet). Egyébként bizonyára véletlen, hogy pont a bináris, gyorsan kereshető logstore az egyik fizetős modul a syslog-ngben, mert az egy akkora baromság, hogy ilyen igénye senkinek nem lehet ;)

szerintem nem szerintem karomkodok szerintem sokat. szerintem csak szerintem nyomatekositasra szerintem hasznalom szerintem az szerintem eros szerintem szavakat.
bar szerintem mindenki szerintem tisztaban szerintem van szetintem vele, hogy szerintem a magam szerintem neveben szerintem beszelek
ha szerintem valakinek szerintem nem kell szerintem a systemd szerintem hadd szerintem dontse szerintem el es szerintem ne kelljen szerintem ugy konfiguralnia szerintem hogy azt kapja szerintem, amiert szerintem nincs szerintem szuksege szerintem a systemd-re
de szerintem ezt ma mar szerintem nem teheti meg szerintem sajnos mert szerintem bedrotoztak szerintem ezt a f@st szerintem midenhova

Vagy az elso szam elso szemelyben beszeles eleg lett volna hogy "szerintem"? :D
Amugy nalunk csak a szopas van vele. De sajnos nem valaszthatunk, mert ott van es kesz. Desktopon meg csak ertem (nem, ez csusztatas), hogy minek kell(ene).

Es nem nem hivtad fel a figyelmemet semmire. Megmondtad, hogy mit kellett volna mondanom, mikor en tudom mit akartam mondani. A TE(!!) velemenyed az az odairt es kiemelt szo. :D
Ez a mod, ahogy ezt hasznaltad pedig eppen olyan banto (leforditom a gyunodat: azt sem tudod igazabol mit beszelsz de en segitek Te szellemi visszamaradott). Nagyon szep nyelvi lelemeny amugy. Viszont magamra vettem (a szemelyemnek szolt) ezert mondhatjuk, hogy szemelyskedtel. Csak Te a gunyt hasznaltad hozza nem a direkt kifigurazast (groupie hasonlat)

Ja, varj csak...lesz@rom :D

"Es nem nem hivtad fel a figyelmemet semmire. Megmondtad, hogy mit kellett volna mondanom, mikor en tudom mit akartam mondani. A TE(!!) velemenyed az az odairt es kiemelt szo. :D"

Nem, még mindig arról van szó, hogy az érvelésed alapja az, volt, hogy a te véleményed az igazság, amihez mérni kell a dolgokat. É

"Ez a mod, ahogy ezt hasznaltad pedig eppen olyan banto (leforditom a gyunodat: azt sem tudod igazabol mit beszelsz de en segitek Te szellemi visszamaradott)"
Nem, nem gúnyolódtam. Félreérted. Tudod te mit beszélsz, csak hibás az érvelésed. Erre meg valahogy fel kell hívni a figyelmedet (és ez a szerintem csak egy viszonylag kompakt módja volt ennek). Ilyen alapon minden ellenvéleményről leírhatod, hogy azt mondta neked a csúnya gonosz bácsi, hogy "azt se tudod mit beszélsz...", és gúnyolódott azon, hogy szellemi visszamaradott vagy (szép önértékelés volt egyébként :P) és máris megérkeztünk az unatkozó amcsi egyetemisták safe place-jéig, ahol nem lehet ellenvélemény, mert az rosszul esik a mimóza kis lelküknek.

"Viszont magamra vettem (a szemelyemnek szolt) ezert mondhatjuk, hogy szemelyskedtel."
Nem, még mindig nem a személyednek szólt.

"Nagyon szep nyelvi lelemeny amugy."
(Figyelj, ez most a személyednek szól :D). Jaja, vannak ilyen szép dolgok a magyar nyelvben, érdemes megpróbálni a káromkodáson kívüli részét is megtanulni, hátha akkor megérted, miről beszélnek neked :D

Keressuk meg azt a par szot, amiben azt jelentettem ki, hogy az en velemenyem az igazsag, amihez masoknak merniuk kell magukat az alabbi mondatban:

"""
szoval konfigoljon a kollega egy programot arra, hogy azt csinalja ami a program nelkul amugy is jol menne...ertem
"""

A fenti mondtaban:
- nem volt kijelentes (kerdes volt ugye)
- sehol nem talalom, hogy ultimate igazsagkent adtam volna elo, biz'isten kersem meg most is :D
- ha nagyon csurom es csavarom hat kiragadhatom a mondat masodik reszenek egy kulon kis reszet: "ami a program nelkul amugy is jol menne"; na ebben sem allitottam valotlant, de plane nem erzem, hogy igy kiragadva is hordozna az "ultimate igazsagom vagyon nekem" dolgot, amin lovagolsz

Ertem en, hogy megbantottam a systemd-t. Ez fajhat. De akkor is egy haszontalan f@s, ami kivalthato siman mas programokkal, amik nem kenyszerito hatasuak es sokkal normalisabb a fejlesztoi gardajuk vagy legalabbis a projekt vezetoje.
!!! FIGYELEM !!!: Az elozo mondat eslo fele egy velemeny, plane a csunya szavak (jujj), viszont a masodik fele teny, hiszen tenyleg vannak disztribuciok, amik ezt megtettek. Nem az en ultimate igazsagom. :D

Ha szamodra valaki velemenye - aki nem ert veled egyet - ultimate igazsagkent eloadott kenyszerito ereju valami, akkor nalad vannak a bajok. :D

A safe place emlitese toled pedig egyenesen brillians, aki nem tudja elengedni, hogy mas velemynen vagyok a systemd-vel kapcsolatban. :D

Sajnalom, hogy ha a kis kedvencedre valaki azt mondta hogy csunya es bottal sem erne hozza. En is megbantodnek, ha valaki ilyet mondana a kedvenceimre.
Ja varj, nem is, mert leszarom. :D

Vitatkozhatunk itt a retorika ismereten, meg be is tamadhatsz, hogy en bizony nem birom ugy a magyar nylevet, mint becses (onmagadnak legalabbis lathatoan nagyon becses) szemelyed, de igazabol ezt is leszarom. :D

Szorakoztatsz az ures perceimben. :D
Majd vissza-vissza nezek azert am, hatha uzentel valami vicceset. :D

"- ha nagyon csurom es csavarom hat kiragadhatom a mondat masodik reszenek egy kulon kis reszet: "ami a program nelkul amugy is jol menne"; na ebben sem allitottam valotlant, de plane nem erzem, hogy igy kiragadva is hordozna az "ultimate igazsagom vagyon nekem" dolgot, amin lovagolsz"

Kár ezen ennyit lovagolni :) Szólval de. pontosan ott állítod a valótlant, amikor a saját véleményedből "ti: a systemd nélküli működés a jó" levezeted, hogy a systemd szar, és röhögsz rajta, hogy made my day. Ami lefordítva kb annyit tesz, hogy "a systemd szar, mert nekem nem tetszik". Ami véleménnyel semmi baj nincs (figyelj, meglepő dolog következik: magam is meglehetős ambivalens érzésekkel viseltetem a cucc iránt), csak helyén kezelendő: érv nélküli véleményként, arra meg kicsit erős úgy csinálni, mintha más mondott volna bazi nagy hülyeséget (lásd még you made my day).

Továbbra is, tőlem nyugodtan tarthatod szarnak a systemdt, csak arra nem nagyon van alapod, hogy ezért kiröhögd BlackY-t.

Meh, engem nem zavar. Viszont jó tudni, hogy ő mindent gyári defaulton hagy, a rendszerein soha, semmilyen módosítást nem végez.

(ahhoz meg már túl sokszor futottam le ezt a kört, hogy szakmai érvek mentén, dokumentációt hivatkozva érveljek, én attól nem leszek kevesebb, hogy ő valamilyen elfogultsága miatt egy lassan ipari sztenderddé váló technológiát nem ismer meg...)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha megismerted volna, tudnád, hogy ez sem sokkal másabb, mint bármelyik program, amit a disztród akarva-akaratlanul valaminek a függőségeként behúz és ha nem tetszik a default beállítása, konfigolnod kell. Qed.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egyébként bizonyára véletlen, hogy pont a bináris, gyorsan kereshető logstore az egyik fizetős modul a syslog-ngben, mert az egy akkora baromság, hogy ilyen igénye senkinek nem lehet ;)

Azért, no! Ne keverjük a szezont-a fazonnal!
A józan észt meg ne tegyük már ki az ablakba postolás előtt!

A syslog-ng nem akar systemd lenni!

De ha már a syslog-ng-t felhozod példaként:
a moduláris szervezés ("driverek" szervezése és modularitása, konfig szervezése: src, dst, path, filter),
a unix filozófia amit a syslog-ng is követ, hogy mindenki csinálja a saját dolgát, valamint azt jól körülhatárolhatóan és csak azt (gyk.:ne legyen űrromboló!) biztos egy oltári nagy baromság a syslog-ng-ben!

Jah, várjunk! Mégsem!
De akkor a systemd-től azt miért is nézed el, hogy az ilyen fent említett alap szervezési irányelveket, meg mindenféle józan ész diktálta módszertant rúg fel, amiket a syslog-ng pl. meg követ?

Tudod hogy az ilyesfajta kettős-mérce egyes emberekben a képmutatóság benyomását kelti?

Egyrészt ez mind hogy jön ide, mikor a bináris log értelmetlen a téma? Nem pedig, hogy csillagromboló-e. Ez ilyen utálom a systemdt stratégia, hogy eloadtok egy csomó dolgot, mintha a másik mondta volna, és jól megpróbáljátok cáfolni?

Másrészt meg majd jon valaki, és bedobja, hogy a systemd ezer apró, akár külön is működő darabból áll. Én nem, mert nekem is szokott csillagromboló érzésem lenni :-)

Mutass már egy bináris systemd konfig fájlt, légyszi.

Az irónia és szarkazmus, mint koncepció ugye megvan neked, hogy mit jelentenek?
Mert spec, ebből a hozzászólásból nem úgy tűnik.

Javaslat: Ne olvass hírcsárdát se! Nem neked való!

Mindenki másnak:
Szerintem Dwokfur hircsárdát felülmúlóan parodizálta pöttering attitűdjét! Én jót mosolyogtam rajta! ;-)

Amúgy meg kezdem azt gondolni, hogy ez az ember (pöttering) egy hős!
Egyensúlyt hoz az erőbe mint Darth Wader!
Kettéválasztja a usereket, mint Mózes a vörös tengert!

Lesz egy inflexiós pont az emberek hangulatgörbéjén, ami ha kellő technikai háttértudással párosul (<troll>: mint pl. tud használni egy olyan egyszerű eszközt mint a vi (ez még nem jelent semmit, csak egy erősen jellemző korreláció! ;-) </troll>) akkor körbenéz a színen és elmegy más unicsok felé.

Saját merítés: a legutóbbi körbenézésemkor azt tapasztaltam, hogy egy freebsd már egészen felhasználóbarát deszktop OS
Bár haverom, aki a saját linuxát kb. 1 éve lecserélte freebsd-re, javasolta, hogy nézzek meg youtube-on valami Zahy nevű embertől videókat, mert úgy tök könnyű beállítani. De valahogy én inkább a doskit néztem meg, és arra jöttem rá, hogy iszonyatosan jól szervezett straightforward valami. Szóval a Zahyval inkább csak egy sört iszok, ha arra járok, nem nézegetem a tecsőn...

Ééés már csak egy ráérős hosszúhétvége hiányzik nekem is, hogy az asztali uborkámról (pontosabban az adatokról) csináljak egy mentést, és hátrahagyjam a vérbe. Bár előbb valszeg megpróbálok makkosx-et hákolni a gépre... Ha az fail, akkor marad a freebsd.
Majd ha ez megvolt, akkor a következő lépés a linux leírtása a laptopomról is.

Lássuk be: A fent emlegetett pöttering féle társadalmi kisérletben való részvétel, teljesen önkéntes beleegyezésen alapul! Ki lehet lépni a mátrixból, még ha sokan nem is látják a lehetőséget! ;-) Azt hiszem, valami ilyesmi volt a nagy gondolat amit összegzésül mondott neó a kissrácnak, aki állandóan megtalálta, és ha jól emlékszem úgy jutott ki a mátrixból, hogy kiugrott az iskolaablakon ;-)

Hidd el, engem nem zavarna a szorosabb systemd integráció az átlagos projektben, de sokak felháborítónak találják (mert az ilyenek, mint a D-Bus, az fúj, mindenki találjon ki saját protokollt mindenre, saját parserrel, mert az a jó). Egyébként nem is kell semmi plusz extra jogkör, ha socket activation-t használsz, ott a programod megkapja a socketet és azt kezd vele, amit akar, és amit tud a saját usere alatt.

Persze ezzel az a gond, hogy ehhez tényleg módosítani kell a programot és beviszel egy (egyébként opcionális) systemd-függőséget.

(egyébként nem teszteltem, de a Poettering-féle systemd for Administrators sorozatban emlegették, hogy megoldható, hogy egy socket aktivált service system-nspawn konténerben fusson)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

én is kíváncsi lennék, ezért is hoztam ide a témát. Pedig én is örültem anno, hogy milyen jó ötlet ez a systemd, csak aztán a jó ötlet mellé kaptunk egy borzasztó megvalósítást.
Javítsatok ki ha rosszul gondolom, de ez egy pont olyan helyzet ahol érvényesülnie kellene az opensource "demokráciának" és a többség véleménye visszaterelné a fejlesztést valami értelmes mederbe. Vagy a többség szerint ez így jó? :D

szinte mindenre van fork, igy kikerulheto a systemd:
udev - eudev
systemd-logind - elogind
stb.

szinte :D

A lenyeg tovabbra is az, hogy a nagy disztribucio gyartoknak egyszerubb egy olyan rendszerre epiteniuk, ami egyetlen nagy absztrakcios layert ad, mint sok kis programmal szarakodni. Persze hogy az egy jo nagy f@shalmaz az nem erdekli oket. Nekik konnyebb igy a dolguk. :D

És ha valakik mégis csak ráveszik Potter Ingét, hogy használja (legalább mások) józan eszét és a következő + 2. verzióban kijavítja illetve elrontja a dolgot, és a számmal kezdődő felhasználóneveket mégse root-nak tekintik, akkor az OBSD fejlesztők is fejvesztve visszavonják ezt a komitot a doas-ból?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem kéne a program elvárt működését egy gráfon vagy akármin (UML?) ábrázolni, és azt leellenőrizni hogy jó-e?
Programozás alapjain így tanultuk.

Az algoritmus helyes, azt valósítja meg, amit akart (formai hibás inputot naplózás után eldob, formailag rendben levő, de érvénytelen [pl. nem létező user] esetén hibát generál). Ezt akármeddig rajzolgathatod, így lesz.

A vita azon megy, hogy jó-e ez a követelmény-specifikáció, ill. kisebb értelemben, hogy az amúgy is megosztó "mi az érvényes usernév" [lásd az összes citált példát a bugreportban a disztrók közti/disztrón belüli inkonzisztens működésre] a legmegengedőbb vagy a legszigorúbb elvet kövessék-e.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem nem helyes az algoritmus. Ha van egy "User=invalid_user", akkor ott a unit fájl hibás és nem szabad a service-t elindítani. Loggolni kell és nem csinálni semmit. Az lényegtelen, hogy az invalid_user azért invalid, mert egy valid usernév és nem létezik, vagy egy invalid usernév.

Halkan kérdezem meg: ha kap egy akármilyen usernevet, miért nem ellenőrzi, hogy létezik-e a user a rendszeren, ha nem, akkor loggol, és nem indítja az adott szervízt. Így nem kell okoskodnia, hogy "vajon számmal kezdődhet-e user?" Meg nincs a fenti megengedő / szigorú usernév dilemma sem.

De a legnagyobb gond, ami miatt agyrém ez az egész ügy (és még hány ilyen lehet az egész systemd-ben!), hogy nem állhatsz úgy neki az init rendszernek, hogy ha valami gond van, majd fallbackelek akármilyen userre, mert "hátha úgyis jó lesz".

Ugyanez van a parseolásnál. Egyértelműen hibás az a koncepció, hogy a unit fájlokban nem áll meg hibával, ha olyan stringet talál, amit nem ért. Pont a User-nél kijön az, hogy a default működés (root-ként futtatás) az megengedőbb, mint amit a unit fájl írója akar (megadott User-ként futtatás). Ez bármely más konfig értéknél is előfordulhat, és szervíztől függően még nagyobb galibát okozhat.

ha kap egy akármilyen usernevet, miért nem ellenőrzi, hogy létezik-e a user a rendszeren, ha nem, akkor loggol, és nem indítja az adott szervízt.

Halkan válaszolom, hogy ha usernevet vagy UID-ot kap, ezt teszi (status=217/USER-al failed állapotba teszi a service-t). Ha formai hibás inputot (ami se nem kizárólag numerikus karakterekből áll, se nem a szigorúbb usernév szabályzatnak nem felel meg) kap a unit fájl _olvasásakor_ (ami a boot folyamat elején történik meg utána _kézzel_ kiadott daemon-reloadra), akkor default-ol a root-ra.

Meg mi van, ha template unitról van szó (foo@.service, aztán a User=%I), mert pl. külön user alatt futó service-t akarsz minden virtual hostnak? Ott döntést legkorábban az instance indításakor tudsz hozni, végképp nem tudod validálni a unit fájlt parse közben (egyébként sem, mert nem csak passwd létezik, a unit fájlok olvasásakor pl. a systemd-sysusers még nem futott le ;)

Ui.: továbbra is, valaki mondjon már egy use case-t a számmal kezdődő usernevekre please.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Tényleges user accountja ritkán kerül service fájlba [én is használok így service-t], de egy workaround-ot lásd fenn (template service-nél nem megy át a formai ellenőrzésen, csak a létezik/nem léteziken)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az enyémben ugyan nincs:

# useradd 0pointer
useradd: invalid user name '0pointer'

Van prior art arra, hogy nem engedik a számmal kezdődő neveket. (ha nagyon unatkoznék, megérne egy kört futni az eltrejedtebb démonoknál, hogy amelyik tud user-t/gid-et váltani, hogy viselkedik ilyen inputra)

Szerk.: Sőt, továbbmegyek. Ha nincs semmilyen megkötés a usernevekre, akkor érvényes usernév a 0 és mondjuk az 1000 is. Igaz? Innentől kezdve _minden_ programot, ami önmaga vált usert és elfogad megkülönböztető jel nélküli (pl. az Apache #-je) UID-et és usernevet is, egyesével auditálni kellene, hogy hogyan működik egy User 0-ra.

Ui.: Mielőtt jönne valaki a POSIX-el, halkan megjegyzem, hogy $ végű nevet viszont simán lehet csinálni (Samba machine account-okra hivatkozva)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Bár ellenkezik az elveimmel, hogy válaszoljak a hozzászólásaidra: egyszerűbb nem megpatchelni az upstream csomagokat (https://github.com/shadow-maint/shadow/blob/master/libmisc/chkname.c vs. RHEL patch: https://gist.github.com/bloerwald/a482791395114fa82636e2ab207cdb11), hogy ilyen hibákat okozhass...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem "ellenkezik az elveiddel" hanem túl alacsonyan vagy kvalifikálva hogy értelmezd őket. Ez a fenti (egyébként megmosolyogtatóan linux-centrikus) értetlenkedéseden ezúttal is egyértelműen tettenérhető.

Különben ez az "igenis lehessen UTF-32 kínai számokkal is UID-et megadni a konfikfálljban mert tájvánban ez tutira reális usecase lehet" (de a számmal kezdődő alfanumerikus username az bezzeg szerinted pont nem) elképzelés már a nemrég lezajlott unicode topicban is csúfosan bukott, csakúgy mint pöcshering is a hülye elképzelésével, amihez te a Mester dicstelen bukása után is ragaszkodsz érthetetlen - ám vicces - módon.

(elvek: akkor te most az N+1. gabu nick vagy vagy sem?)

Ha megköveteled, hogy nem-szám karakterrel kezdődjön egy usernév, azzal _egyértelműen_ elkülöníted az uid-októl. Ha legalább odáig eljutott volna a RHEL patch, hogy megkövetelje, hogy _valahol_ legyen benne egy nem-szám karakter, még mindig megkülönböztethető lenne (kivéve, amikor az okos kóderek simán egy atoi-vel mennek neki letiltva a 0 visszatérési értéket, mert akkor az 123jóska helyett az uid=123-al indítod...).
Jelen formájában egy "adduser 0" után a User=0 szerinted melyik uid-el induljon?

(egyébként a további POSIX sírás után: a fenti RHEL patch továbbra sem POSIX kompatbilis, mivel nem vizsgálja ezt a kitételt:

The character should not be used as the first character of a portable user name.

)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nincs UID opció. Just saying. Innentől kezdve hoztál egy újabb kérdést: ha mindkettő definiálva van egy unit-hoz (figyelj, unit != unit fájl, több helyen kiegészíthető), melyiket vegye figyelembe? Az egyetlen (bár az is backward-incompatible) opció, ami minden kétértelműséget megold, az a uid-ek prefixelése lenne (pl. #uid, amit itt-ott használnak is).

Vagy tudod, ne patcheljük a shadow-utilst, hogy lehessen számmal kezdődő usernevet csinálni...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ahhaha. Te aztán szénné égve is minden hülyeségbe belekapaszkodsz.

Igen, hogyne, hát naná hogy kell egy kettőskereszt prefix a számok elé, különben honnan is tudnák a számokat váró opciók, hogy számok fognak következni?.. Újabb pötterizmus. Persze állítólag "itt-ott" használják is.

Igen, természetesen az - amúgy szintén csak pallérozott elmédben létező - programnak kell "kitalálnia" hogy két konfliktoló opció közül melyiket akarja használni, nehogy hibaüzenetet adjon, lefagyna a milleniálisok agya (például a tied).

Nem tudom ezen a héten arrafelé mi a "shadow-utils", minden UNIX rendszeremen lehet számmal kezdődő usernevet csinálni, csak a reteklinuxodon csináltak ebből műproblémát :D

Az "or, you know" angol kifejezés tükörfordítása a magyarban röhejesen hat, én a helyedben nem erőltetném.

Persze állítólag "itt-ott" használják is.


$ sudo -u0 id
sudo: unknown user: 0
$ sudo -u#0 id
uid=0(root) gid=0(root) csoportok=0(root)

$ su  - 0
su: user 0 does not exist
$ su  - #0
Jelszó:

Igen, természetesen az - amúgy szintén csak pallérozott elmédben létező - programnak kell "kitalálnia" hogy két konfliktoló opció közül melyiket akarja használni, nehogy hibaüzenetet adjon, lefagyna a milleniálisok agya (például a tied).

És ezzel azonnal el is törted a drop-in könyvtárakat - ha adhatsz egymásnak ellentmondó direktívákat, akkor vagy nem tudod felüldefiniálni a disztró defaultját (kivéve, ha az _egész_ unitot felüldefiniálod) vagy igenis meg kell határoznod egy sorrendet.

a reteklinuxodon csináltak ebből műproblémát :D

És jé, úgy tűnik, még értelme is van, mert rengeteg problémát okoz.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

vagy igenis meg kell határoznod egy sorrendet

Segítek: ha felüldefiniálós setupot csináltál, akkor a felüldefiniáló konfig fájlét használjuk, a felüldefiniált konfig fájlét meg nem. Ez egy egzakt sorrend, igaz, nem abszolút sorrend, de könnyedén leprogramozható, teljesen determinisztikus, és pont azt fogja adni, amit az ember várna.

Ez oké, csak nvik két külön direktívát akar ugyanarra használni...
/usr/lib/systemd/system/foo.service (<- vendor unit fájlja)

[Unit]
...

[Service]
User=foo

/etc/systemd/system/foo.service.d/runas123.conf

[Service]
UID=123

/etc/systemd/system/foo.service.d/runasbar.conf

[Service]
User=bar

foo-ként, bar-ként vagy uid=123-ként fusson? Mi a "teljesen determinisztikus" sorrend ilyen esetben (csak User direktívával a runasbar nyerne, fájlnév szerinti sorrend)?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A fenti példából a következőket lehet determinisztikusan leszűrni:

1. Van a rendszeren systemd. Solution: azonnal ACPI poweroff, a rendszer kompromittált.

2. Az OS készítői jó ötletnek tartották a rákos lófasz.d elrendezést. Solution: elvileg szükségtelen, mert a gép már off. De ha a rutin ezen a ponton mégis még mindig fut, a root filerendszer teljes törlése megtörténik, majd kernel panic-ra ugrunk.

3. A retardált user kihasználva a lófasz.d marhaságot, két, faszságot tartalmazó cfg file-t hozott létre. Solution: ha idáig nem sikerült a rendszer megsemmisítése, el kell indítani mindent amit csak lehet, hátha attól összeomlik.

Mi a "teljesen determinisztikus" sorrend ilyen esetben

Amit később olvasott fel a parser. Mivel tuti nem multithreadben olvassa a konfig fájlokat (ekkora hülye még a kis Poetsch sem lehet), így biztos, hogy van sorrend. Nekem magától értetődő, hogy ezt determinisztikussá kell tenni.

Determinisztikus.

Oks, akkor ha a legutoljára beolvasott fájlba teszek egy UID és egy User direktívát is?

User=foo
UID=123

(oks, erre fogod hozni, hogy az uid=123, mert az szerepelt utolsóként. ezután ha introspektálom a unit-ot, mit írjon a User= sorhoz? Az utoljára olvasott User= értéket (foo) vagy a UID-hez tartozó usert? Vagy onnantól kezdve keresgéljek mindig két értéket, és tudjam, hogy melyik az aktív? Vagy rejtse el azt, amelyiket felülbíráltam? Vagy...)

szvsz. akkor már inkább legyen csak egy User= és prefixelni kelljen az uidet.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ha a legutoljára beolvasott fájlba teszek egy UID és egy User direktívát is?

Miért tennél? Mondj egy "use-case"-t arra, amikor az UID és a User is kell!

De ha nagyon akarsz determinisztikus viselkedést, akkor szerintem a legjobb az lenne, hogy uid(foo)==123 esetén rendesen elindulna foo nevében, ellenkező esetben meg vagy írja ki, hogy a kettő nem egyezik, vagy legyen valamelyiknek dokumentált prioritása.

akkor már inkább legyen csak egy User=

És akkor mi legyen a viselkedés, ha kettő User-sort kap?

És akkor mi legyen a viselkedés, ha kettő User-sort kap?

Ez már most is meg van, az utolsó ilyen sort használja (mint az összes direktívánál, ami nem ismételhető).

De ha nagyon akarsz determinisztikus viselkedést, akkor szerintem a legjobb az lenne, hogy uid(foo)==123 esetén rendesen elindulna foo nevében, ellenkező esetben meg vagy írja ki, hogy a kettő nem egyezik, vagy legyen valamelyiknek dokumentált prioritása.

Vagy legyen _egy_ direktíva, ami a futtató user-t állítja olyan szintaxissal, hogy egyértelműen megkülönböztethető legyen egymástól egy uid és egy user név...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez már most is meg van, az utolsó ilyen sort használja (mint az összes direktívánál, ami nem ismételhető).

Akkor lehetne akár a User és UID megadott esetében is, hisz mindkettővel egy felhasználóra hivatkozol, amit nyilván minek ismételni.

Vagy legyen _egy_ direktíva

Akár.

ha introspektálom a unit-ot, mit írjon a User= sorhoz?

Az attól függ. Ha teljesen újra akarom generálni a konfig fájlt, akkor kidobom a noop sorokat (jelen esetben a nem legutolsót), ha csak azokhoz a sorokhoz akarok hozzányúlni, amit változtatok, akkor nyilván a legutolsó sort megváltoztatom, az előtte levőkhöz meg nem nyúlok (marad ugyanúgy noop).

A működés logikája szerintem semmiben nem különbözik attól, mintha lehetne több User= sor is, és mindig az utolsó számít. Csak a user fogalomhoz itt két különböző keyword is tartozhat, amik kölcsönösen felülírják egymást.

$ su - #0
zsh: bad pattern: #0
$ su - \#0
su: unknown login: #0

Egyéb hülye sorminta lesz még ma? A minden szabvánnyal MS-módra inkompatibilis linuxod amúgy kutyát se izgat. Mondjuk aki a rendszerén lyukware sudo-t tart, attól minden kitelik: és lám, itt vagy te.

Nem tudom mit vered magad itt az "egymásnak ellentmondó direktívákon", amikor te hoztad fel őket hogy legyenek. De még opción belül is ugye, mert Pöttering.

"Disztrót" ugyan sikeres ember nem használ (különben oda jut hogy pl. Kurt Roeckx szabja meg hogy mit mennyire titkosíthat, és Pöttering hogy milyen userneveket szabad az eheti patchlevelen beírnia), de a hülyeségeddel ellentétben a defaultok felülbírálása sosem volt probléma, a konfigfileok priorizálása miatt. Érvelni meg úgy tűnik elfelejtettél. :)

Nem tudom mit vered magad itt az "egymásnak ellentmondó direktívákon", amikor te hoztad fel őket hogy legyenek. De még opción belül is ugye, mert Pöttering.

Hát persze, aki szerint az User= opció csak usernevet, az UID= opció pedig csak UID-et fogadjon el, az érveljen.

Te voltál, aki felhoztad a UID= opciót.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Akkor: "ha mindkettő definiálva lehet egy unit-hoz"... most jobb? Ugyanott vagy, egymást kizáró direktívák, amit valahogy fel kell oldanod. Vagy nem engeded meg, hogy ilyen helyzet előállhasson.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az enyémben ugyan nincs:

Works4me? :)

# pw user add 0pointer
# pw user show 0pointer
0pointer:*:2001:2001::0:0:User &:/home/0pointer:/bin/sh

man chown:

The owner may be either a numeric user ID or a user name. If a user name is also a numeric user ID, the operand is used as a user name.

Korábban nvik is ezt írta.

POSIX szabványra mutogatva a GNU chown is így megy, azzal kiegészítve, hogy adnak az egyértelmű megkülönböztetésre egy prefixet (http://www.gnu.org/software/coreutils/manual/html_node/Disambiguating-n…)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ah, sejtettem, hogy még csak oda kellett volna írnom, hogy mit is akartam mondani.

Szóval egyrészt az egyik lényeg, hogy FreeBSD esetén annyira lehet akár csak számokat tartalmazó júzernevet használni, hogy még a chown-ba is beírják, hogy ebben a speciális esetben hogyan viselkedik. A linkeden található infó alapján az szűrhető le, hogy Linux esetében is(!!!) megengedett az ilyen júzernév (azaz akár az összes karakter lehet csupa szám is). Ezt az eddigi lehetőséget zárná ki a systemd.
A másik lényeg, amit szerettem volna kihozni, hogy a nem egyértelmű esetekben történő viselkedést le kellene dokumentálni, mint ahogy a kétfajta chown esetében ez meg is történt (kár, hogy a GNU-manuálban nincs benne, tovább meg nem kerestem - köszi!). Nem bogarásztam át a systemd-dokumentációt, de a bug reportból úgy gondolom, ez bizony nincs leírva. Ha más nem, a hibajegy "not-a-bug"-ra állítása mellett a dokumentációban egy bekezdést lehetett volna szentelni ennek a furcsa viselkedésnek.
A harmadik lényeg pedig egy költői kérdés lenne: ha kb. a kezdetek óta az alaprendszerhez tartozó chown-nak nem okoz gondot a számos júzernév, és a speciális eseteket is kezeli, miért ne tudná ezt megtenni a systemd is? Akár még pont a chown logikája szerint?

Persze, hogy megengedett, tudod kézzel szerkeszteni a passwd fájlt. Attól még szvsz. bad practice, pont azért, mert speciális edge case-ket generál. A systemd pedig nem zárta ki, azt zárta ki, hogy az ilyen userekre _név_ alapján hivatkozz (User=uid formában továbbra is hivatkozhatod ill. fentebb írtam, hogy akár template unitként is), jóval korábban a shadow-utils kezdte el tiltani.

Hogy nincs dokumentálva, azon nem veszünk össze, valóban nincs (bár a sysusers.d man oldalán szerepel, hogy mit gondolnak usernévnek:

The name field specifies the user or group name. It should be shorter than 31 characters and avoid any non-ASCII characters, and not begin with a numeric character. It is strongly recommended to pick user and group names that are unlikely to clash with normal users created by the administrator. A good scheme to guarantee this is by prefixing all system and group names with the underscore, and avoiding too generic names.

Melyik chown? :) Egyébként a GNU-st még támogatnám is, visszafelé többé-kevésbé kompatibilis lenne az edge case-ket leszámítva (edge case: létezik user sima numerikus névvel és egy másik ugyanilyen uid-del, a unit fájl az uid-es userre hivatkozik), de az is egyértelműsíthető lenne (+, #, ... akármivel).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

speciális edge case-ket generál

Igen, viszont pl. a chown esetében ebben a speciális esetben ismert ("determinisztikus") a viselkedés.

systemd pedig nem zárta ki, azt zárta ki, hogy...

Bocs, valóban, pontatlanul fogalmaztam.

jóval korábban a shadow-utils kezdte el tiltani

Értem. Akkor viszont ott a gond, hogy a core-utils (chown) és a shadow nem egyformán vélekednek erről. Kellene egy egységes linuxos álláspont ezügyben, és akkor talán a systemd ezen furcsasága is megoldódna :)

Nálad ez van:

# useradd 0pointer
useradd: invalid user name '0pointer'

Nálam pedig ez:

# useradd 0pointer
# adduser 1pointer
adduser: Please enter a username matching the regular expression configured
via the NAME_REGEX[_SYSTEM] configuration variable. Use the `--force-badname'
option to relax this check or reconfigure NAME_REGEX.
# adduser --force-badname 1pointer
Allowing use of questionable username.
Adding user `1pointer' ...
Adding new group `1pointer' (1006) ...
Adding new user `1pointer' (1004) with group `1pointer' ...
Creating home directory `/home/1pointer' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for 1pointer
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
# getent passwd | grep pointer
0pointer:x:1003:1005::/home/0pointer:
1pointer:x:1004:1006:,,,:/home/1pointer:/bin/bash

Szóval ha jól értelmezem akkor a !pöcsfejing világban simán létezik számmal kezdődő username.
És erre normális esetben nem az a válasz, hogy akkor körbedrótozunk mindent, hogy ne engedjen olyan viselkedést, ami nem illik abba a rendszerbe, ahogy pöcsfejingnek sikerült megírnia a systemd-t, basszus. Az meg hogy root-ra fallback-el, az meg tényleg mindennek a csúcsa.

És erre nem a "not-a-bug" a normális válasz, hanem egy "a büdös**ˇ^°[đ][Đđ] életbe de elbasztam, bocsánat, javítom ASAP". Szeirntem.

+1

Ugyanezt csinálta a pulseaudio-val. Használt olyan függvényt, amit addig senki, íg az ALSA-ban hol implementálva volt, hol nem, hol rosszul, recsegett, ropogott a hang. Amikor kitört a balhé, meg sem próbálkozott workaround-dal, hanem a logba bejegyezte, hogy kéretik az ALSA driver maintainerét piszkálni ezügyben, 0pointer urat meg békén hagyni. Remek. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

> És erre nem a "not-a-bug" a normális válasz, hanem egy "a büdös**ˇ^°[đ][Đđ] életbe de elbasztam, bocsánat, javítom ASAP".

De ő inkább kijelenti, hogy ez a normális és a világ igazodjon hozzá. Ismerős tempó, a körte kicserélése helyett inkább belevette a szabványba a sötétet.

Nem az a baj, hogy a számmal kezdődő userneveket nem engedi, hanem azzal, hogy ha invalid karaktert tartalmazó usernevet talál, akkor eldobja a User= sor-t és teljes lelki nyugalommal rootként kezdi futtatni ahelyett, hogy hibával megállna.

Az a baj ezzel a koncepcióval, hogy a véletlen elírásra is (a direkt manipulációt ne is említsük) privilégiumszint emelés történik mellékhatásként. Nekem pl. a billentyűzetkiosztásom AltGr + Space-re egy ideig (hibásan) nem space-t, hanem egy space-nek látszó másik unicode karaktert adott ki magából, amit lehet, hogy invalid usernek ítélt volna a Systemd. De ha mentéskor véletlenül beírsz egy !-jelet a usernévbe, és nem veszed észre, már kész lehet a baj.

Ezeket le lehet söpörni "user error" címszóval, tehát a felhasználó hibája. De úgy gondolom, hogy egy védőhálónak (bemeneti adat ellenőrzése) nem úgy kéne működnie, hogy ha bizonyos szögben futsz neki, akkor átesel rajta...

Ráadásul én például nem tudom, mely felhasználónevek legálisak. Az egyik felhasználónevemben van pont karakter. Ez legális? Úgy emlékszem, volt olyan program, amelyik nyafogott miatta, vagy legalább is valamit rosszul csinált, mert ezt sikerült azzal tetéznem, hogy a pont utáni része megegyezik egy másik user nevével. Tehát másik az egyik részhalmaza.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

attól függ mit használsz. jó pár rendszer tiltja (pontosabban a pont nem engedélyezett karakter júzernévben). igazából ott lehet para, ahogy írod is, hogy ha vmi programod "ragaszkodik" ezekhez, vagy alapvetően azt feltételezi, hogy te "szabályszerűen" jársz el, és emiatt rosszul parse-olja az adatodat. mindenesetre megkerülhető ez is, nem véletlenül létezik a "--force-badname" és annak alternatívái :)