Forum Debian Users Gang

vega napisał(-a):

Żeby cokolwiek zainstalować najpierw wpisuję su i hasło

Dlatego nie działa.

Ale to nie ma z tym nic wspólnego ;)

w dodatku nie mogę teraz uruchomić Synaptica choć przedtem się uruchamiał więc pomyślałem, że to od tego, że coś cię pochrzaniło z uprawnieniami.

Ostatnio edytowany przez vega (2018-09-28 15:48:42)

dziękuję yossarian. Temat do zamknięcia.

yossarian napisał(-a):

Samo su nie działa tak jak dawniej.
Przy aktualizacji był stosowny komunikat.

Kiedy był ten komunikat? Bo ja chyba przeoczyłem go, choć ja od początku używałem "su -", by resetować środowisko, co poprawia znacznie bezpieczeństwo pracy na root. xD

Od pewnego czasu trzeba dawać też:

$ xhost si:localuser:root

By graficzne appki się uruchamiały pod root.

Już znalazłem:

util-linux (2.32-0.4) unstable; urgency=medium

  The util-linux implementation of /bin/su is now used, replacing the
  one previously supplied by src:shadow (shipped in login package), and
  bringing Debian in line with other modern distributions. The two
  implementations are very similar but have some minor differences (and
  there might be more that was not yet noticed ofcourse), e.g.

  - new 'su' (with no args, i.e. when preserving the environment) also
    preserves PATH and IFS, while old su would always reset PATH and IFS
    even in 'preserve environment' mode.
  - new 'su -' (creating new environment) will do just that, while old
    su would always preserve content of DISPLAY and XAUTHORITY
    environment variables. Set them as needed (but beware X doesn't give
    you any real privileges separation anyway if you can access an X
    server of another user). See pam_xauth(8) if you want to reconfigure
    pam for seamless xauth keys.
  - su '' (empty user string) used to give root, but now returns an error.
  - previously su only had one pam config, but now 'su -' is configured
    separately in /etc/pam.d/su-l. This file additionally invokes
    'pam_keyinit' to revoke the session keyring.

  The first difference is probably the most user visible one. Doing
  plain 'su' is a really bad idea for many reasons, so using 'su -' is
  strongly recommended to always get a newly set up environment similar
  to a normal login. If you want to restore behaviour more similar to
  the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.

 -- Andreas Henriksson <andreas@fatal.se>  Fri, 03 Aug 2018 10:52:22 +0200

No, wiedziałem, że to z xhost jest przez to właśnie. xD

Ostatnio edytowany przez morfik (2018-09-28 18:00:30)

Ja korzystam z tego i z tego. Ale gdybym miał przy każdym poleceniu dodawać jeszcze "sudo ", to by mnie szlag trafił. xD

morfik napisał(-a):

Ja korzystam z tego i z tego. Ale gdybym miał przy każdym poleceniu dodawać jeszcze "sudo ", to by mnie szlag trafił. xD

Dlaczego?

sudo -i

w terminalu i możesz zrobić pierdylion rzeczy przez cały dzień, i sudo użyć tylko raz.

Poza tym do rożnych rzeczy możesz zrobić aliansy z sudo, np:

alias reboot='sudo  /sbin/reboot'
alias poff='sudo  /usr/sbin/poff'
alias pon='sudo  /usr/sbin/pon'

RTFM:

man sudoers
man alias

SOA#1

Ostatnio edytowany przez Jacekalex (2018-09-29 13:26:37)

yossarian napisał(-a):

Normalne dystrybucje nie wymagają uprawnień administratora do wyłączania/restartowania systemu ;)

A co to takiego te "normalne dystrybucje"?

Pamiętam, jak pewne "normalne dystrybucje" dały użyszkodnikom prawo zmiany czasu systemowego, co pozwoliło ujawnić katastrofalny błąd w sudo.
Błąd, którego nie dało się znaleźć w warunkach, kiedy tylko root mógł zmienić czas systemowy.

W każdym razie przez kilka tygodni łatwiej było shakować lokalnie taką "normalną dystrubucję" niż zjeść bułkę. xD

Ostatnio edytowany przez Jacekalex (2018-09-29 14:10:42)

yossarian napisał(-a):

....
Dotyczyło to chyba tylko jednej dystrybucji, z normalnością nie mającej nic wspólnego — Ubuntu.

Nie tylko *buntu i jego klonów, ale także MacOSa.

Ja wolę wszystkie sprawy dotyczące koniecznej eskalacji uprawnień trzymać w jednym/dwóch miejscach, nie przepadam za automatyką Consolekit/Policykit/SystemD,
bo po prostu im więcej automatyki, w której system myśli za użyszkodnika, tym większe ryzyko różnych nagłych niespodzianek, które czasem mogą kosztować dużo zbędnych nerwów.

Nienormalna dystrybucja Gentoo u mnie wyłącza kompa przez przycisk Power na obudowie (z poziomu Acpid a nie jakichś wynalazków typu upowerd i podobnych), natomiast

sudo pm-susped

uruchamia przycisk usypiania na klawiaturze, podpiąłem do niego to polecenie kosztem
15 sekund  ciężkiej pracy na konfigurację. xD


Natomiast błędów związanych z politykami bezpieczeństwa PolicyKIt już widziałem wystarczająco dużo.

SOA#1

Ostatnio edytowany przez Jacekalex (2018-09-29 14:34:08)