KUbuntu, root passwords and broken authentication (was Re: Ubuntu & Linspire)

Sat Feb 10 00:06:21 UTC 2007

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).  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.  So I may be coming full circle into an 'update existing machine with
original users' pitfall.

> >> Regardless of the password you type in (root or user) it's wrong and
> >> does not authenticate.  So by setting a root password you are forced
> >> to login as root to make admin changes for ever more.
> 
> No, root can edit the pw and group files, removing himself, and the 
> old way works again.

Well, yes,  I could also boot the install disks in and re-install the whole
system to put things back 'the way they were', but then that doesn't really
count either ;)  If you have to set the root user back to original to make it
work, then logic follows that you can't make it work after you set the root
password.  Changing the root entry of the shadow file 2 or 3 times a day isn't
a workable solution.

> >That would be a nasty problem and a good argument that the current sudo
> >setup is, indeed, somewhat broken.
> >
> >> And it's damned annoying being prompted for a password in KDE when you
> >> know darned well it's not going to work.
> >
> The only reason it doesn't work for me is that the new user (or root)
>  doesn't have privileges on the currently running xscreen.  But I 
> found an xhost command that fixes that.
> 
> >Absolutely.  Do you have any idea /why/ it doesn't work any longer?
> >
> >As far as I knew the kdesu simply ran sudo to achieve root access; sudo
> >doesn't care one way or the other if root has a password or not.
> >
> >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.

> >> 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.  In fact, to the best of my recollection, that IS kdesu's purpose
in the first place?  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.  If there's a way to restore (I mean
modify) this in Kubuntu I'd like to know.  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".

<snip>

> >>> I guess "hardcore" users don't own Wacom tablets, but they do own USB
> >>> mice, right?
> >>>
> >>> I infer this because you whine about Wacom tablets being configured
> >>> to work "out of the box" but we don't hear complaints that xorg.conf
> >>> contains definitions for USB mice...
> >>
> >> You don't hear complaints about definitions for USB mice because they
> >> don't generate warnings about missing devices everytime you start an
> >> application in X.
> >
> >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. :)

Hey, what you do in the comfort of your custom kernel is entirely your
business, including any warnings created because of it ;)  Seriously though,
if it were me building a custom kernel (not that I've done that in quite a
while now), I'd include the mouse support (needed or not) just for the
security of knowing that X isn't travelling down any un-neccessary error
handling code.  The risk of including buggy mouse handler (which isn't used
and doesn't generate any errors) is much less than the risk of excluding it
and allowing an error handler to deal with it's absence.  Nirvana would be
finding the reason for the warnings in the first place and getting the code
fixed upstream, but that's not much of an option for most people.  Sadly we
have to live with warnings (and errors) when it's beyond our control.  The
Wacom tablet warnings IMHO weren't beyond Kubuntu's control.  They were simply
ignored with nobel excuses.

Just to be clear, I'm not directing my comments to you or any particular
individual on the list, but to the (k)ubuntu community as a whole.

<snip>

> >Yeah.  The lack of support for hotplug or dynamic management of input
> >and output devices in the X code is a pretty serious lack -- especially
> >in this day and age.
> >
> >Thankfully Keith Packard is resolving that, and we can expect x.org 7.2
> >(which may make Feisty and will make the release after that) to resolve
> >this problem.
> >
> >Then, finally, when you add a new keyboard (or Wacom tablet, or
> >whatever) X will be able to notice that, load the driver and start using
> >it.

I'll drink a beer to that!

> >> Ignoring the messages that was given is just plain bad advice.
> >> Encouraging it is irresponsible.
> >
> >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).  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.

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. 
Problem hardware is still problem hardware but anything that can be made to
work usually does from the get go.  I'm highly impressed with Kubuntus clean
and simple install, but it's a fleeting impression that quickly pops when you
find mis-configured devices you don't own.

And I also heartily agree, there's no right answer here.

Scott

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