Happier with kdesudo

[Duncan]

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 at cox.net> 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.