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

[Daniel Pittman]

"Scott Mazur" <kubuntulists at littlefish.ca> writes:
> On Fri, 09 Feb 2007 12:26:07 +1100, Daniel Pittman wrote
>> Joe Hart <j.hart at orange.nl> writes:
>> > Jonathan Jesse wrote:

[...]

>> > Sudo/Root?
>> 
>> Good security practice?  Is it that hard for a "hardcore" user to run
>> 'sudo passwd root' -- I mean, seriously.
>> 
>> These are the "hardcore!"  They know how to use the command line, and
>> it isn't like Ubuntu prevents you setting a root password -- or even
>> blinks if you do.
>
> I agree (or have no opinion) about everything you've said up to this
> point. It's true Kubuntu doesn't prevent you from setting a root
> password (I've done so myself, becuase that's just the kind of user I
> am).  

So have I, in the past, for a variety of reasons.

> But it's not true there are no consequences to this.  Every (and I
> mean EVERY) configurable option in KDE that needs admin rights prompts
> for a password.  Out of the box that's fine (whether you agree it
> should be any old user password or root only). 

*nod*

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

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

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.

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.

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


>> > Wacom devices in xorg.conf?
>> 
>> 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. :)

> When they do, advice is given to fix the config, not 'ignore the
> error'. I want to be clear about something: Developers spend time
> making code work. They don't spend time making writing (let alone
> testing) 'exception' events to ensure they've cleaned up properly.
> What you see as a harmless X error that means nothing and should just
> as well be sent to the NULL bucket, I see as a hole in the code (in
> this case X, which is a big part of the system to have a hole in).

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.

[...]

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

Regards,
	Daniel

Footnotes: 
[1]  ...even if Wacom devices /should/ have worked through the Linux
     input event system years ago, and X should have supported that
     years ago.

[2]  ...which don't bother most users.

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