KUbuntu, root passwords and broken authentication

[Scott Mazur]

On Sun, 11 Feb 2007 11:15:44 +1100, Daniel Pittman wrote
<snip>
> > Something someone said in another thread got me thinking.  This was a
> > kubuntu clean install, on an existing Linux box.  After install the
> > root password is set, things are checked/updated and finally the
> > original users /home uid/passwords are returned.  The snippet I'm
> > remembering is something about only the first user created gets sudo
> > access during install, and that's the first user to be removed after
> > returning the original users.
> 
> Ah!  So, correct me if I am wrong, but you are:
> 
>   A)  Deleting all the normal users created during the install process.
>   B)  Creating new users with their own UID and group memberships.
> 
> During B are you assigning any users to the 'admin' group?
> 
> If not then, well, at least we know why those users cannot access 
> root via sudo.
> 
> If you /are/ adding them to the admin group, but sudo is still 
> failing, then you should report this as a bug.  This is ... 
> definitely that, since that is absolutely not the way that sudo 
> should behave -- ever.

Yes, that is exactly what I'm doing.  Adding users to the admin group does in
fact 'get things working' again.  My bad choice of timing for setting root
password before any other post-install actions :(  Could have saved quite a
bit of un-focused ranting ;)

<snip>

> > Not to say that it does/should work this way, but I would expect (as a
> > Linux admin with no previous Kubuntu experience), that if I should set
> > a root password, then kdesu should accept a root password to authorize
> > admin rights when needed.
> 
> Ah.  You "assume."
> 
> Linux, as a rule, doesn't have a policy of "magical" changes.
> 
> Assigning a root password has, as experienced Unix users would normally
> expect, absolutely zero effect on the configuration of other
> applications such as sudo.
> 
> The consequence of this, of course, is that when 'kdesu' uses sudo to
> 
> (try to) obtain root privileges it doesn't care about, or consult, 
> the password for root.
> 
> If you want sudo to prompt for the root password it is possible to
> configure it to do so -- but you have to explicitly make that 
> change.
> 
> > In fact, to the best of my recollection, that IS kdesu's purpose in
> > the first place?
> 
> No.  The purpose of kdesu is to run graphical applications with other
> privileges than those of the current user.
> 
> It provides a graphical password prompt, confirmation that the user
> wants to take the action, and provides some degree of environmental
> management to unsure the target application works.
> 
> It is *not* designed to "authorize admin rights with the root password;"
> that is the *mechanism* it uses, not the driving purpose of the tool.

Ah, you "assume" kdesu's purpose is to run applications with other privileges.
 That probably justifies kubuntu's position to substitute the 'su' of kdesu
with sudo.  kdesu's purpose IS to provide su (root) access when needed.  You
don't have to take my word for it, this is evidenced by the fact that any user
not in the 'admin' group is pestered for password they can't possibly provide.
    Done right, users outside of the admin group wouldn't be offered the
choice to enter administration mode or at least be allowed to enter an
alternate user with the password.
 
> Also, consider a situation in which a hardware token was proof of access
> to administrative privileges.  Would you insist that kdesu was doing 
> the wrong thing because it consulted the token, not the password?

That's exactly the situation where sudo is the appropriate tool.  It's also a
situation where you wouldn't use kdesu to do it either.  I use sudo for just
such reasons, which makes me even more leery when the desktop starts messing
with it.

> > Whether kdesu should be authorized by a regular user password can be
> > left to the never ending sudo debate.  But for a regular user not to
> > be able to use the kdesu mechanism with a root password for it's
> > intended purpose just doesn't seem right.
> 
> It may not be what you expect but, with kdesu configured to use the
> 'sudo' backend rather than 'su', it will correctly continue to use sudo
> to obtain elevated privileges.

But only if you're in the 'admin' group.  Kubuntu users aren't coming in cold.
 Anyone with no prior Linux experience could have fired up Ubuntu and been off
without a second thought.  I'd probably recommend Ubuntu over Kubuntu to a
newbie.  Kubuntu users are coming in expecting the KDE experience with KDE
"assumptions" in tow.  Why bother creating kubuntu otherwise?  If you have no
assumptions, then there's also no reason for the choice.

> > If there's a way to restore (I mean modify) this in Kubuntu I'd like
> > to know.
> 
> Your two choices are to rebuild the KDE packages with local
> modifications, so they use the 'su' backend rather than 'sudo', or...
>
> ...modify the configuration of sudo so that it uses the root password
> rather than the current user password.  Plus any other configuration
> changes to match what you want of course.
> 
> That is documented in sudoers(5) manual page.
> 
> > Then we could really put the sudo argument to rest with a simple
> > "here's how you can set a root password so kdesu respects it".
> 
> 1. Set a root password.
> 2. Set the 'rootpw' or 'targetpw' flag in /etc/sudoers

Set the 'rootpw' flag was exactly what I wanted.  The actual syntax of how to
turn it on was harder to find than I would have thought, but end result is
what I wanted.

Fun as the experiment is though, I'm going to have to put sudo back to the
install default and work with the user passwords.  Adjusting sudo's default
behaviour for reasons of the desktop is just bad karma in my book.  Points to
Kubuntu for creatively modifying KDE to use sudo.  Maybe more work on the KDE
side of things will improve kdesu authorizing options without resorting to
hacking in sudo.  One of the things I like most about Kubuntu is that I find
it sticks more closely to the standard KDE than other distros.  But on closer
examination it appears the Kubuntu is no different for all it's customizing.

> 
> [... meanwhile, rather less on topic ...]

Ya, sorry :)

<snip>

> Not being the person who made the decision I can't give an authoritative
> answer here, but knowing people who have been involved in similar
> decisions:
> 
> Wacom (and compatible) tablets are not nearly the luxury item you
> suggest; they are actually pretty common in some parts of the world.
> 
> They are also, with the drivers and configuration in question,
> unambiguous.  Only a Wacom tablet will be detected and used.
> 
> On the other hand, serial mice.  They are /not/ unambiguous, and they
> require non-trivial additional configuration to work as expected.
> 
> They are also a pretty uncommon item these days.  Not unknown,
> certainly, but it is actually hard to buy anything but a USB mouse now.

It's also hard to buy anything but an optical mouse now (yeah finally!) but I
still have to put up with sticky balls and ps2 mice every where I go, when all
I really want is my trusty track ball.  I certainly have never set up serial
mouse for Linux (actually, come to think of it our first windows computer
which got switched to linux may of had a serial mouse, but it's long since
gone).  We're all biased towards what we have available in our reach.

If it had been a Wacom keyboard or mouse at issue I would have silently fixed
my Xconfig and not whispered a word.  These are primary input devices they
must just work.  If they don't you can't even try to fix it post-install.  Any
and all steps taken to ensure they 'just work' out of the box are justifiable,
even if that means trivial errors and post-install corrections.  But come on,
a graphics tablet?  If Kubuntu believes this MUST be installed by default,
then I can't help but be skeptical when they say they work at being 'the
distro for everyone'.  Attention to detail is the only thing separating one
distro from another.

> So, the decisions were:
> 
> Wacom: reasonably common, supports a wide range of hardware, no risk 
> of incompatibilities, some errors from X applications.
> 
> Serial Mouse: not so common, high risk of incompatibility, requires
> hardware knowledge from the user to configure.
> 
> Independently that stacks up, at least for Ubuntu, to Wacom in,
>  Serial mouse out.
> 
> > The way I see it the choice was made for it to work out of the box for
> > a few and 'potentially' cause problems for the much larger majority of
> > others.
> 
> I think you are significantly overstating the risk and understating the
> degree of testing undertaken by Ubuntu here.
> 
> > Maybe it's just me, but making things work out of the box just isn't
> > that big a deal anymore.  All the big distros handle hardware quite
> > magically these days (to lessor and greater degrees) and installs have
> > been easy for years.
> 
> Yes.  The Wacom thing is, in fact, part of the work that makes that
> "just happen."

I sure hope your right.  My gut's been right too many times before to ignore
it now ;)

Scott

-- 
Registered Linux user #395249, http://counter.li.org
Nothing goes to waste when Little Fish are near!
(http://www.littlefish.ca)