[sf-lug] GKsu has long been EOLed

[Rick Moen]

Quoting Akkana Peck (akkana at shallowsky.com):

> I have a root password and can su to root just fine.
> It was the PermitRootLogin part in sshd_config that I didn't have
> (and I definitely wouldn't want to add it except with the limitation
> to localhost, which you mention later.)

FWIW, if you guesstimate the requirements for guessing ssh passwords
from remote, you can see that any competently selected root password is
staggeringly unlikely to succumb to remote dictionary attack, because
it'd just be too slow.

For example, Internet server linuxmafia.com (that runs this mailing
list) permits root login from the global Internet, though I can't
remember needing or using that in ages and I might at some point disable
it in /etc/ssh/sshd_config.  Dictonary attacking won't get it, nor the
usual permutations on dictionary attacks, nor would knowing me let
anyone figure it out, so brute-forcing is what remains and would take so
many decades to have even a 1% chance of succeeding as to be not worth
worrying about.

It always amuses me that the same people who feel virtuous disabling
root login (or root ssh access from remote hosts) nonetheless tend to
use discoverable usernames that can not only ssh in but then can supply
the same password to sudo to escalate directly to root.  So, it's
basically cargo-cult security -- a Potemkin village.

Or, to put it a different way, if you consider allowing root to ssh in
too risky, then by the same token allowing a non-root user who can
root-escalate with the same password to ssh in raises exactly the _same_
risk.


> In a way, I can sort of understand that. As a contrarian who uses a
> relatively minimal openbox windowmanager, I'm forever hitting things
> that don't quite work because I don't have some daemon or have
> uninstalled some service, and I have to waste a bunch of time
> chasing workarounds. Sometimes it feels like it would save a lot of
> time if I'd just put up with Ubuntu and its defaults.

You might think that -- but it turns out that the Ubuntu/Apple approach
saves time chasing workarounds primarily by shutting you down with
'that's just not supported/included, sorry'.  (Being told 'nope' _does_
save time, admittedly.)


> Today's timewaste: gqrx, a software defined radio program that won't
> install without PulseAudio even if you have no intention of using it
> for audio and just want to look at the FFT.

PulseAudio (from the systemd guy) has become quite a plague.  (Gosh,
package dependency hairballs involving Poetteringware!  Who knew?)  In
case you haven't heard of it, 'apulse' is often a good trick to finesse
PulseAudio dependency, in many cases.

Quoting https://github.com/i-rinat/apulse :

  [apulse] provides an alternative partial implementation of the
  PulseAudio API. It consists of a loader script and a number of shared
  libraries with the same names as from original PulseAudio, so
  applications could dynamically load them and think they are talking to
  PulseAudio. Internally, no separate sound mixing daemon is used.
  Instead, apulse relies on ALSA's dmix, dsnoop, and plug plugins to
  handle multiple sound sources and capture streams running at the same
  time. dmix plugin muxes multiple playback streams; dsnoop plugin allow
  multiple applications to capture from a single microphone; and plug
  plugin transparently converts audio between various sample formats,
  sample rates and channel numbers. For more than a decade now, ALSA comes
  with these plugins enabled and configured by default.

  apulse wasn't designed to be a drop-in replacement of PulseAudio. It's
  pointless, since that will be just reimplementation of original
  PulseAudio, with the same client-daemon architecture, required by the
  complete feature set. Instead, only parts of the API that are crucial to
  specific applications are implemented. That's why there is a loader
  script, named apulse. It updates value of LD_LIBRARY_PATH environment
  variable to point also to the directory where apulse's libraries are
  installed, making them available to the application.

It's basically a PulseAudio-emulation _shim_, intercepting the app's
PulseAudio calls and converting them to bog-standard ALSA calls, thus
letting (most) PulseAudio-afflicted applications run on standard systems
not infected by the Borg ^W^W^W^Whaving the PulseAudio sound daemon
running.

It'd be better if the damned app vendors would bother including regular
ALSA suport and not just assume every Linux has Poetteringware, but a
number of apps' developers have fallen into that error (**cough**
Firefox **cough**).

So, to use the shim, you would run gqrx by doing 'apulse gqrx'.

Hope that helps!