Kevin Chadwick posted on Mon, 31 Dec 2012 15:54:24 +0000 as excerpted:
> On Sat, 29 Dec 2012 00:46:16 +0000 (UTC)
> Duncan <1i5t5.duncan@xxxxxxx> wrote:
>
>> Kevin Chadwick posted on Fri, 28 Dec 2012 21:06:03 +0000 as excerpted:
>>
>> > How can I switch from polkit-kde-authentication back to kdesudo auth
>> > in KDE 4.9.
>>
>> I don't have a direct answer to your question, but [...]
>
>> What I've done here (on gentoo where it's actually reasonable to have
>> kde without polkit, etc), is setup normal terminal-based sudo, with a
>> policy not to use the X gui for anything superuser based at all.
>>
>>
> I did similar on Arch but I'm leaving due to systemd and have no
> problems without polkit on xfce, though I don't use network manager.
Yeah, I had read about Arch getting engulfed by the "gray goo" that is
systemd...
>> Instead, I use mc (midnight commander, ncurses/slang based) with it's
>> commander-style "semi-gui" in a terminal, or the traditional CLI, for
>> any "sysadmin hat" tasks, including text/config file editing, file
>> management, etc.
>
> Is that via sudoedit?
I'm not sure what "that" refers to, but in general, yes.
Actually, being a typical sysadmin in that I like my commonly used
commands as short as possible:
s ... invokes sudo (with the same bash-completion scripts hooked to both)
e ... invokes mcedit (in normal user mode)
se ... invokes sudoedit (which in turn invokes mcedit as EDITOR=/l/bin/
e, /l/ being my mountpoint for the normal /usr/local/, which here is is
simply a symlink to /l/ )
mc ... naturally invokes mc (normal user mode)
smc ... invokes s mc (mc in superuser mode via sudo)
I also have an (X-based) hotkey (the details of my hotkey setup would be
another post, unfortunately, khotkeys4 lacked the flexibility of
khotkeys3 and I had to hack up my own setup) configured to launch a
konsole shell as my normal X/KDE user (for normal user mode work), and
another to launch konsole with bash running as my admin user alterego
(konsole -e bash -e <script to sudo bash as the admin user>). Thus, with
a couple keys I can launch a konsole bash session as either my normal
user, or (with password) as my admin user.
It's that admin user that has full passwordless sudo/sudoedit access. My
normal X/KDE user is MUCH more locked down, with one of the few
exceptions being that it can sudo (with password) a bash session as the
admin user.
So my normal user has only very (sudoers) restricted superuser access in
any case, to tcptraceroute and a few other selected commands, with the
big one being that it can sudo a bash session as the admin user. It's
only the admin user that has full passwordless sudo access.
With that kind of setup, it was both easier and already fit the general
policy, to not allow the normal X/KDE user any graphical superuser access
at all. And since again by policy, neither my admin user nor root ever
starts an X session, that means no X/KDE superuser access -- all
superuser tasks are done via text term, either using a bash session
directly, or using mc.
>
>> For typically "user hat" tasks like multimedia
>> (image, movie, audio) usage and management, I use the GUI, typically
>> gwenview for images and movies, dolphin for audio and textfiles as
>> gwenview doesn't handle that, but for everything else, including
>> editing kde's user config itself when I end up actually handling the
>> textfiles, I find the combination of mc and standard CLI commands works
>> just as efficiently for me, if not more so.
>>
>> A few months ago, the last time a topic like this came up on the kde
>> lists, I actually tried kdesu and kdesudo and discovered they no longer
>> even worked.
>>
>>
> Yeah I'm generally quite happy with sudoedit, sed etc. and use install
> scripts. I couldn't find kdmrc however and so wanted to fire it up via
> kdesudo without running the whole of system-settings as root. Turns out
> Sabayon (my attempt to get gentoos power without the compilation) seems
> to use the kdmrc in /usr/share????!!!??? that I took as a reference
> file. I've tried finding out about $KDEDIR or how the kdmrc location is
> configured but no luck yet. I'm just testing at the moment but if I
> decide to use Sabayon I will likely use startx anyway.
I haven't used a ?DM in years (since my Mandrake Cooker years, 2003ish,
their DM quit working and I switched to startx and never looked back). I
login at the CLI, then run a script (called "k", nice and short!) that
sets up a few vars including XSESSION=kde4, then runs startx (in the
background), waits a few seconds, and exits back to the bash prompt (or
logs out if I source the script, . k). By that time of course, X is
starting in its VT, and I don't see the CLI unless I ctrl-alt-F? back to
it until I quit kde/X.
>> Somewhere along the line I had decided my normal user didn't need to be
>> in wheel (the group with su access) and I didn't feel the need to
>> revert that decision,
>
> I've never bothered with wheel even on OpenBSD. Whenever it's useful I
> see more specific options to my case that are easily setup.
Well, wheel is the group that has access to su, and a few other things.
My admin user is in wheel (so can su if sudo is broken or something), but
my normal user isn't.
>> so that didn't work, and while sudo still worked, my sudo policy here
>> only lets my normal user do a few limited things, including sudoing to
>> an "admin" user, which is far less restricted. But of course said
>> "admin" user doesn't then have access to the existing normal user X
>> session, so couldn't run any X-based commands anyway. And again, yes,
>> I could fix that, but I realized that I really had no need to do so --
>> everything I needed to do as admin, I was quite comfortable doing in mc
>> or at the CLI, and the tiny bit of trouble I might occasionally save by
>> running some GUI admin program wasn't worth the hassle of setting up
>> and ensuring the proper security of the access necessary to do so.
>>
>>
> I agree but worry about some cases, perhaps vmware or some systems where
> I will want to use kdesudo and not polkit. These programs should be able
> to request to run specific binaries via kdesudo rather than encouraging
> the whole thing. I realise that in this case it could be done on the CLI
> too. I expect it must be possible as I can't see all apps supporting
> polkit.
Well, vmware's proprietary servantware that I couldn't legally run on my
own systems even if I wanted to, as I can't agree to the EULAs, for
various reasons. (Among other things, I won't agree to waive damages and
take responsibility for any software that I don't have the freedom to
inspect the sources of without signing an NDA. I don't believe it's
possible to have a fair meeting of the minds and be able to /take/ such
responsibility without the ability to inspect those sources, or have
someone I trust inspect them, since I'm not a coder, so I don't believe
they have the /right/ to ask me to do so. Since the legal system here
unfortunately holds differently, I simply can't run that software, since
I can't agree to those waivers.)
So vmware's out (just as are servantware video drivers, servantware
flash, servantware ...).
And in general, I've simply not found anything where it's /enough/ more
trouble to run the CLI version as opposed to the GUI version, that it's
worth the trouble and security worries to configure for GUI superuser. I
just do all my superuser tasks via CLI and don't worry about superuser in
GUI mode.
Meanwhile, as someone else commented in that article you linked, be aware
that in X, it's always possible for every application in the X session,
to have full access to every other application the X session. As such,
if you're running a single X application in superuser mode, security-wise
(tho not fat-finger-wise, which I'd argue is actually more important),
you might as well be running them all in superuser mode.
This is the one that opened /my/ eyes.
http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-
gui-isolation.html
And if you might as well be running everything in superuser mode, why not
just do your X login as root in the first place?
In point of fact, the fat-finger protection is reason enough. However,
the point stands, if you're worried about security, you simply don't run
ANY X apps in superuser mode, period. Because any other app in that X
session can see what's going on in the superuser app, send input to it,
etc.
(Actually, strictly speaking the same applies to running root or admin-
user sessions in a konsole window. Ideally, you only do superuser tasks
from a non-X VT, or alternatively, have a dedicated superuser X login,
where EVERYTHING's running as superuser and you know it, so you don't
access the net from it or anything, only do superuser stuff in it.
However, I've not actually gotten to that extreme yet and do still run
admin and superuser CLI sessions in konsole, tho I'm definitely aware
that I'm not strictly following security "best practice". One step at a
time... I weened myself off of superuser GUI access. Hopefully at some
point I'll ween myself off of superuser CLI access but in an X-based
terminal window, too.)
Meanwhile, if you ARE interested in GUI apps that can't spy on each other
and on superuser GUI apps as well, consider looking up QubesOS (as in the
blog linked above). Developed by Invisible Things Lab out of Poland (CEO
is Joanna Rutkowska, she knows here stuff as she wrote the infamous "Blue
Pill" demo rootkit, undetectable in its time and still close to it), it's
a Fedora derivative that uses Xen-based VMs to isolate individual X/
graphical tasks from each other. On topic here as the UI is KDE-based
=:^)
http://en.wikipedia.org/wiki/Qubes_OS
http://distrowatch.com/table.php?distribution=qubes
http://www.google.com/search?q=qubesos
>> My suspend/hibernate solution is something I scripted myself,
>
> I may be interested in that, if it's little trouble.
I'll followup with an explanation and attach it.
>> and on the netbook, I have laptop-mode-tools configured for power
>> management , so don't have/need kde's power management tools
>> (powerdevil and etc) installed, either.
>>
>>
> Does laptop-mode-tools not work on your desktops then?
I guess you're not familiar with laptop-mode-tools and it needs a bit
more explanation.
What laptop-mode-tools does is provide an automated way to control a
bunch of things related to laptop power usage at once. In general, the
idea is to use the power-plug/unplug events to automatically trigger such
things as kernel laptop-mode (the original use, from which the name
sprang), which sets several disk write cache parameters so as to allow
the disk to spin down and remain spun down for longer periods (minutes at
a time, but write everything possible when it is spun up) in ordered to
conserve battery (vs standard mode, where dirty data is generally written
within 5-10 seconds maximum). But from that original beginning, laptop-
mode-tools now ships with (individually configurable, naturally) scripts
that hook into the same triggers, to manage everything from screen
backlighting (if active, dimmer on battery), to sound chip (power-save
mode on battery) to ethernet (if you're on battery, chances are you're
either on wifi or not connected, power down the ethernet entirely),
to ... well, there's quite a list.
So the idea of laptop-mode-tools is to automatically configure the system
to conserve battery when ON battery, and automatically return to
performance mode when on wall power. As such, while it's possible to
trigger manually, the whole idea isn't something that always-wall-powered
desktop/workstation users are likely to find all that useful.
Meanwhile, just to be clear, I run the same suspend/hibernate script that
I wrote myself, on both the workstation and the netbook. It's designed
to be invoked from symlinks such as s2standby, s2ram, s2disk, s2both
(s2both only on recent kernels, 3.6+ IIRC), detecting what it was called
as, and taking the appropriate action accordingly. On the workstation,
the kernel had some issues with s2disk (and thus s2both) last time I
tried that, but fortunately, s2ram is extremely reliable, and wall power
is stable enough here that I just use that, or simply power-off if I'd
otherwise s2disk. (What's interesting is that my old workstation, s2ram
didn't work at all and s2standby was flaky, but s2disk worked reasonably
well. It was 2003 vintage but dual socket, each of which was dual-core-
opteron-390 thus quad-cores overall so powerful enough, and I only
replaced it last summer when a mobo capacitor leaked and others were
bulging, but after 9 (!!) years... Anyway, the new one is the exact
opposite, s2ram works great, s2disk doesn't) On the netbook, I use both
s2ram and s2disk, with both working extremely reliably. (I don't update
it as frequently, and don't believe I'm running a new enough kernel on it
to do s2both yet, or at least I've not tried it, if so.)
That's not at all the same as what laptop-mode-tools does. So different
tools for entirely different purposes, and I run my suspend scripts on
both but laptop-mode-tools on the netbook only, since the workstation has
little use for that.
>> Actually, given that I have USE=semantic-desktop turned off as well (so
>> no akonadi thus no kdepim, substituting gtk-based replacements like
>> claws- mail), while I do run a kde desktop, all the above means it's
>> actually relatively slim. Package numbers don't mean a lot across
>> distros but for gentooers this will mean something: 110 packages in a
>> kde upgrade for me including nearly all kdegames. I guess a full kde
>> install with all the trimmings is several hundred more. (IIRC mine was
>> 250+ before I started trimming the fat, tho even that wasn't all of
>> kde.)
>>
> Very interesting, I assume you still have konqueror. I prefer konqueror
> to dolphin with kfind by default, filesizeview plugin and folder and
> file bookmarks. I may switch to spacefm when it gets full bookmarking
> though.
In the interest of accuracy, I had mis-remembered and that 110 wasn't
quite correct, as that was the number of packages in a kde update after
I'd already updated kdelibs and a few others. On this last update (I'm
running 4.9.97 aka 4.10-rc2 now), I checked, and the actual number of kde-
core (IOW, not including stuff like kde-look-sourced plasmoids that
aren't shipped with and don't update in sync with kde-core) packages was
161. But as I said, it was certainly far higher before I started
trimming the fat.
Yes, I still have konqueror. Of course konqueror in file management mode
uses the dolphin kpart, so the core is the same, but the wrapper around
it is different, and it's that difference that can MAKE the difference.
Altho... I'm actually thinking of uninstalling konqueror...
One thing about gentoo is that since it's build-from-source, every
package installed as a non-zero cost as you build every update. I look
at it this way -- it's great encouragement to follow what is best
security practice anyway, only keeping installed the packages I actually
USE.
For people like me that run kde pre-releases, there are at least 8
updates to build every six months! (Two betas and two rcs, plus four
monthly releases, .0 thru .3 before the first beta for the next feature
release. There's an extra rc for 4.10, so it's getting three rcs instead
of the normal two.)
That's a LOT of kde updates I'm building! No WONDER I'm interested in
keeping a slimmed down kde! =:^)
And since I switched to firefox as my default browser (the kde devs are
simply not serious about konqueror security and treat it as a toy, with
few enough of /them/ running it as their default; my browser is not a
toy, it's what I use for banking), and use mc on the one hand and gwenview
on the other for most of my file management tasks, with dolphin sufficing
for the rest, really, the biggest reason I still have konqueror installed
is that I've not yet decided to actually uninstall it. Yes, it's nice to
have a second GUI browser (I also have links and lynx setup for console
browsing, when I'm not in X), and the konqueror file management GUI is a
bit less limited than dolphin's, in some ways, but I don't use it /that/
much, and given a kde update cycle of two weeks to a month, depending on
whether kde's in release or pre-release mode... I really am debating
whether it's time to cut some more kde fat.
As for the filesize view, there's the stand-alone fsview program.
konqueror simply embeds its kpart for filesize view. Without konqueror,
one can still run the standalone program (which must be installed anyway,
to get that kpart for konqueror).
It's also worth noting the similar filelight program, also kde. Similar
to fsview, it shows relative sizes, but in a radial view that's more
directory centric than individual filesize centric. Each is useful in
its own way. I find filelight easier to work with as the hierarchy is
clearer, but fsview is better for finding the biggest structures
/regardless/ of tree depth, since filelight's sizes are only directly
comparable at the same depth level.
If you run them both you'll quickly see what I mean. filelight is
hierarchy centric and thus easier to use when working with paths, while
fsview is pure size centric. What's nice, tho, is that after you've run
one and it has fetched the data for its calculations, the other one does
its scan really fast, as the data is all in cache. So it's easy to run
both at once, using fsview to get the absolute size comparisons, and
filelight to see relative directory sizes at the same depth, and find the
paths.
As for kfind, I've not used that in quite some time. I tend to either
use mc's find, or grep or find at the CLI (usually mc or grep, as I'll
admit to not having properly mastered find's many options yet, so I have
to look them up in the manpage, and by the time I do that, mc or grep is
simply easier).
And as I said, I have USE=-semantic-desktop set, so don't have the
benefit (or the cost, which I'm unwilling to pay for that to me very
limited benefit) of kde's semantic searches. Neither do I use a (CLI)
locate variant, for much the same reason. I naturally organize things
well enough that I can normally pin down to a subdir or two, and at that
level, it's easy enough to grep or ls or find or mc search in realtime
for the file I want, so it's really not worth the hassle cost of all that
file indexing and the space it takes, and I prefer to do without. For
the folks that stick a file somewhere and then can't find it, or who have
an entire desktop overflowing with icons of stuff they've stored there
because they don't know how to organize, yes, semantic-desktop might
arguably be worth the trouble. But that's not me.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
