Boycott systemd

[mobinmob]

Εμένα πάντως το παράπονό μου τελευταία είναι ο journald. Έχει μόνο global ρύθμιση για μέγεθος και/ή διάρκεια των logs. Δεν μπορείς να σβήσεις τα logs ενός μόνο unit.
Φανταστείτε πόσο εύκολο είναι για κάποιον να βάλει το unit του να παράγει logs με το κιλό για να αναγκάσει τον journalctl να σβήσει τα logs όλων των services, κάνοντας τα forensics αδύνατα.

Αν στέλνεις τα logs σε κάποια υλοποίηση του syslogd δεν λύνεται το πρόβλημα; Εκεί μπορεί να γίνει φιλτράρισμα.

- - - Updated - - -

Εκείνο το πρόβλημα με τα corrupted binary logs το διόρθωσαν οι αχρείοι ή ακόμα έχουμε μείνει στη γελοία απάντηση του παπάρα του Poettering που είχε κλείσει το bug χωρίς να φτιάξει τη μαλακία που έκαναν;;

Αν εννοείς την απάντηση στο σχετικό bug report, δεν έχω ακούσει για κάποιο σχετικό πρόβλημα εδώ και καιρό. Νομίζω πως η πολιτική αντιμετώπισης παραμένει η ίδια.

[mrsaccess]

Αν στέλνεις τα logs σε κάποια υλοποίηση του syslogd δεν λύνεται το πρόβλημα; Εκεί μπορεί να γίνει φιλτράρισμα.

Αν είναι να ασχολούμαι ώρες με workarounds ζήτω που καήκαμε. Μου επιβάλλουν το journald, ας φροντίσουν να παρέχουν την βασική λειτουργικότητα.
Στην τελική είναι θέμα ασφάλειας, δεν μπορεί από την μια η RedHat να μας πρήζει με το SELinux και από την άλλη να επιτρέπει τέτοια attacks στα system logs out of the box.

[mobinmob]

Αυτό που προτείνω (ανακατεύθυνση στον syslogd) είναι η default συμπεριφορά σε debian και ubuntu αν δεν κάνω λάθος, δεν είναι κάποιο... hackish workaround. Συμφωνώ, δεν θα έπρεπε να χρειάζεται, αλλά υποστηρίζεται

[mobinmob]

Systemd should be better than it is, but it is still our best init system
https://lobste.rs/s/9jxdsi/systemd_s...an_it_is_it_is

Δείτε και τα link που έχει στο post.
Προσωπικά διαφωνώ με το συμπέρασμα

[mobinmob]

https://github.com/systemd/systemd/issues/5644

[imitheos]

https://github.com/systemd/systemd/issues/5644

χεχεχε. γμτ θα είχαμε επική συζήτηση αλά bumblebee αλλά κλειδώνει όλες τις συζητήσεις ο π...ης.

[mobinmob]

Θυμόμουν ότι είχε υλοποιηθεί υποστήριξη για τo tmpfiles.d του systemd στο openrc. Έχει πια περάσει σε ξεχωριστό utility (opentmpfiles). H υλοποίηση είναι σε posix sh, για την διαγραφή αρχείων χρησιμοποιεί την rm και προφανώς δεν έχει το ίδιο bug με την υλοποίηση του systemd

[megahead13]

https://github.com/systemd/systemd/issues/5644

Ο άνθρωπος δεν παίζεται:

I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?

Καλά του λέει κάποιος:

For some people it's advisable to never miss a chance to stay silent.

Παρεμπιπτόντως το δοκίμασα σε ένα test RHEL7 VM και φυσικά το σύστημα δε μπουτάρει τώρα

[karakou]

Νομίζω κακώς τον κράζουν όλοι για αυτό. Κάτι ανάλογο είναι να κάνεις π.χ στο
/etc/rc.d/rc.local

#!/bin/sh
rm -rf /

και να λες είναι bug του sysvinit γιατι δε προβλέπει οτι μπορεί ο χρήστης να διαγράψει το σύστημα
(στο περίπου).

[megahead13]

Καμία σχέση όμως

Από την άλλη αυτή η εμμονή ότι το systemd πρέπει να τα κάνει όλα και όχι απλά να είναι ένα init system

[imitheos]

Νομίζω κακώς τον κράζουν όλοι για αυτό. Κάτι ανάλογο είναι να κάνεις π.χ στο
/etc/rc.d/rc.local

#!/bin/sh
rm -rf /

και να λες είναι bug του sysvinit γιατι δε προβλέπει οτι μπορεί ο χρήστης να διαγράψει το σύστημα
(στο περίπου).

Παραβλέπω ότι δεν παίζει αυτό που λες στο rm όπως του λένε και κάποιοι στην issue (σε κάποια έκδοση των coreutils εδώ και κάμποσο καιρό μπήκε καλώς ή κακώς μια δικλείδα που δεν επιτρέπει στην rm να τρέξει όταν το όρισμα είναι σκέτο / και πρέπει να γράψεις --yes-pretty-please-delete-root).

Επίσης δεν πιστεύω ότι είναι το ίδιο το να γράψεις εσύ χειροκίνητα rm -rvf / ή να φαίνεται ξεκάθαρα σε κάποιο script με το να είναι συνέπεια parsing ενός cryptic κώδικα τύπου "R! /foo/.* - - - - -" αλλά παρόλα αυτά να δεχτώ ότι είναι το ίδιο. Πρέπει να δίνεις πάντα προσοχή σε αυτό που λες στον υπολογιστή να κάνει.

Σε αυτή την περίπτωση όμως είχαμε κάτι εντελώς διαφορετικό. Το "globbing" της συνάρτησης βλέποντας σαν όρισμα το ".*" εκτός από τα αρχεία δούλευε και με το ".." το οποίο είναι γελοίο. Ούτε στο DOS δεν γίνονταν αυτά. Και οι σαύρες ξέρουν ότι . και .. είναι ειδικοί κατάλογοι και δεν λαμβάνονται υπόψην σε τέτοιες δουλειές.

/tmp% mkdir test
/tmp% touch test/file1
/tmp% touch test/file2
/tmp% touch test/.hidden1
/tmp% rm -rvf test/.*
removed 'test/.hidden1'

Όπως βλέπεις σβήνονται όλα τα αρχεία που αρχίζουν από τελεία και βρίσκονται από τον κατάλογο /tmp/test και έπειτα. Δεν λέει το rm "το .* κάνει match και το .. οπότε ας πάμε να σβήσουμε τα πάντα στο /tmp και μετά να πάμε και στο / και να σβήσουμε τα πάντα και εκεί".

Ούτε ένας φοιτητής που πάει να γράψει για εργασία ένα απλοϊκό rm δεν κάνει τέτοια λάθη. Για να είμαι πιο δίκαιος, το πρόβλημα με το systemd είναι η aggressive προώθηση που του έκαναν. Με το να το προωθούν τόσο πολύ και να μπει στις διανομές τόσο γρήγορα, έβαλαν στον εαυτό τους πολύ φόρτο. Έπρεπε να είναι feature complete σε πολύ σύντομο χρονικό διάστημα με συνέπεια να κάνουν τσαπατσούλικη δουλειά και να βλέπουμε τέτοιες βλακείες συνέχεια.

[karakou]

Παραβλέπω ότι δεν παίζει αυτό που λες στο rm όπως του λένε και κάποιοι στην issue (σε κάποια έκδοση των coreutils εδώ και κάμποσο καιρό μπήκε καλώς ή κακώς μια δικλείδα που δεν επιτρέπει στην rm να τρέξει όταν το όρισμα είναι σκέτο / και πρέπει να γράψεις --yes-pretty-please-delete-root).

Επίσης δεν πιστεύω ότι είναι το ίδιο το να γράψεις εσύ χειροκίνητα rm -rvf / ή να φαίνεται ξεκάθαρα σε κάποιο script με το να είναι συνέπεια parsing ενός cryptic κώδικα τύπου "R! /foo/.* - - - - -" αλλά παρόλα αυτά να δεχτώ ότι είναι το ίδιο. Πρέπει να δίνεις πάντα προσοχή σε αυτό που λες στον υπολογιστή να κάνει.

Σε αυτή την περίπτωση όμως είχαμε κάτι εντελώς διαφορετικό. Το "globbing" της συνάρτησης βλέποντας σαν όρισμα το ".*" εκτός από τα αρχεία δούλευε και με το ".." το οποίο είναι γελοίο. Ούτε στο DOS δεν γίνονταν αυτά. Και οι σαύρες ξέρουν ότι . και .. είναι ειδικοί κατάλογοι και δεν λαμβάνονται υπόψην σε τέτοιες δουλειές.

/tmp% mkdir test
/tmp% touch test/file1
/tmp% touch test/file2
/tmp% touch test/.hidden1
/tmp% rm -rvf test/.*
removed 'test/.hidden1'

Όπως βλέπεις σβήνονται όλα τα αρχεία που αρχίζουν από τελεία και βρίσκονται από τον κατάλογο /tmp/test και έπειτα. Δεν λέει το rm "το .* κάνει match και το .. οπότε ας πάμε να σβήσουμε τα πάντα στο /tmp και μετά να πάμε και στο / και να σβήσουμε τα πάντα και εκεί".

Τώρα παρατήρησα ότι η τέλεια είναι πριν τον αστερίσκο, νόμιζα ήταν μετά, οπότε έχετε δίκιο, σόρρυ, ναι είναι τρελό bug.

[pmav99]

Για να είμαι πιο δίκαιος, το πρόβλημα με το systemd είναι η aggressive προώθηση που του έκαναν. Με το να το προωθούν τόσο πολύ και να μπει στις διανομές τόσο γρήγορα, έβαλαν στον εαυτό τους πολύ φόρτο. Έπρεπε να είναι feature complete σε πολύ σύντομο χρονικό διάστημα με συνέπεια να κάνουν τσαπατσούλικη δουλειά και να βλέπουμε τέτοιες βλακείες συνέχεια.

To άλλο φάουλ που κάνουν είναι η πολύ κακή επικοινωνιακή διαχείριση.

[mobinmob]

Παραβλέπω ότι δεν παίζει αυτό που λες στο rm όπως του λένε και κάποιοι στην issue (σε κάποια έκδοση των coreutils εδώ και κάμποσο καιρό μπήκε καλώς ή κακώς μια δικλείδα που δεν επιτρέπει στην rm να τρέξει όταν το όρισμα είναι σκέτο / και πρέπει να γράψεις --yes-pretty-please-delete-root).

Ναι, δεν παίζει και γι' αυτό δεν υπάρχει το πρόβλημα με το opentmpfiles του openrc που ακολουθεί το ίδιο "spec".
Καλώς το έχουν κάνει - η ίδια περίπου συμπεριφορά υπάρχει σε solaris εδώ και χρόνια και συμφωνεί με τα standard. Θυμάμαι σε κάποιο επεισόδιο του BSD Now podcast μιλούσε για το συγκεκριμένο χαρακτηριστικό του rm ο Bryan Cantrill και για το πως κατέληξαν να κάνουν στην σχετική αλλαγή.

- - - Updated - - -

Χμμμ... Τελικά μάλλον θυμόμουν λάθος - η ιστορία με το rm του Solaris είναι λίγο διαφορετική, αλλά με το ίδιο αποτέλεσμα και υπάρχει σε σχόλιο του hacker news από τον ίδιο:
https://news.ycombinator.com/item?id=8896812

[giorgosts]

https://muchweb.me/systemd-nsa-attempt/