KUbuntu, root passwords and broken authentication

[Daniel Pittman]

"Scott Mazur" <kubuntulists at littlefish.ca> writes:
> On Fri, 09 Feb 2007 08:34:43 -0500, Gene Heskett wrote
>> On Friday 09 February 2007 01:11, Daniel Pittman wrote:
>> >"Scott Mazur" <kubuntulists at littlefish.ca> writes:
>> >> On Fri, 09 Feb 2007 12:26:07 +1100, Daniel Pittman wrote
>
> <snip>
>
>> >> But once you set a root password none of the KDE password prompts
>> >> work.
>> >
>> >Ouch.  Which version of KUbuntu was this (fairly serious) bug introduced
>> >in?  This worked in the past, though I don't have a GUI enabled system
>> >with a root password at present.
>> 
>> Its pretty true for kubuntu-6.06.
>
> I'm using Kubuntu Edgy (sorry, don't know a version number although all
> updates are current).  

Well, that is strange -- so am I, and it "just worked."

> 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.

[...]

>> >I can't see anything in the source code that would cause this either.
>> >Very strange and annoying.  Oh, well, let me test this out...
>> >
>> >OK, root has a password and I can su to root successfully.
>> >
>> >Now, to try an admin requiring KDE operation ... and no.  It all just
>> >worked, exactly as I would expect.  I can run both GUI and console
>> >applications through kdesu -- as expected -- after assigning a root
>> >password.
>> >
>> >So, with Edgy this definitely works out of the box as expected.
>
> hmmm... More evidence towards my 'install with existing users' theory.

*nod*  It certainly /sounds/ like you might be causing this drama during
your user setup post-install process.

>> >> It shouldn't have to be that way.  Everyone should set a root password
>> >> just to understand how mucked this action makes your system before
>> >> commenting on how 'trivial sudo is'.  That by and far is my biggest
>> >> grudge against Kubuntu, and yes weighted against the things I like
>> >> about Kubuntu, so far things balance out.
>>
>> >Well, since you undoubtedly did encounter this problem I would encourage
>> >you to try and replicate it and, then, report it as a bug.  It is, after
>> >all, precisely that -- a bug somewhere in the system.
>
> 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.

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?

> 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.

> 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

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

>> >Have you tried running X applications under Ubuntu on a custom kernel
>> >without the mouse support built in?  It will, after all, generate
>> >warnings then. :)

[...]

>> >I think, personally, that the Ubuntu developers made the right
>> >trade-off of problems here.  More hardware working out of the box[1]
>> >is a reasonably trade-off against a few years where unpleasant
>> >warnings[2] are emitted seems a reasonable engineering decision to
>> >me.
>> >
>> >There is no right answer here, only different bad choices.
>
> You know, I really do agree with the spirit of that statement.  I
> guess I'm wondering why the bad choice in this case involved a 'luxury
> item' graphics tablet, but didn't include a lower end serial mouse as
> another poster found (which does tend to 'just work' in other
> distros).  

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.


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."

Regards,
        Daniel

Footnotes: 
[1]  Courtesy, I think, the Ubuntu developers, but still an upstream
     feature.

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/