Damn Small Linux - Not!

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

This might be a problem with seamonkey, cups, dsl-n, or I'm doing something wrong...

dsl-n-01RC3

boot: dsl dma base norestore secure

Enter root password with a special character, for instance "#", like this:

Enter password for root: cat#dog Re-enter: cat#dog Accepted.
Enter password for dsl: dog#cat Re-enter: dog#cat Accepted.

Click on DSLpanel
Click on Printing/Cups
Click on Printer Setup
Click on Do Administration Tasks

User Name: root
Password: cat#dog

Click on OK

Then, the password prompt re-appears.

Click on Cancel
Close seamonkey
Open root shell and change root password to "catdog". Now, it works.

EDIT: The problem appears to be that cups is looking for the password in /etc/passwd
while the secure cheat code updates /etc/shadow.

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

Oops! I should have tested more variations. Wrong subject line. It should be:

cups doesn't recognize secure cheatcode password

If I use:

Enter password for root: catdog Re-enter: catdog Accepted.
Enter password for dsl: dogcat Re-enter: dogcat Accepted.

Then cups still does not accept the password.
After closing seamonkey and changing the root password to "cat#dog",
cups does accept the password.

It appears that the password has to be set from the command line
before cups will accept it. If I:

Enter password for root: cat#dog Re-enter: cat#dog Accepted.
Enter password for dsl: dog#cat Re-enter: dog#cat Accepted.

And then when the desktop appears, open a shell and change the root password
to "cat#dog", then cups will accept the password.

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

Here's a little more info.

The root password in /etc/shadow IS set by the secure cheatcode.
Before I ran Printer Setup, the entry in /etc/shadow was this:

root:nS3bnCSfQk3Go:13374:0:99999:7:::

Running Printer Setup, cups did not accept the root password.

Then, after closing seamonkey, running passwd from a root shell with the exact
same password that I used for the secure boot cheatcode, /etc/shadow now has:

root:nS3bnCSfQk3Go:13374:0:99999:7:::

And then, cups did accept it.

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

The first time Printer Setup is run, /var/log/cups/error_log has:
I [15/Aug/2006:01:54:03 +0200] Listening to 0:631
I [15/Aug/2006:01:54:03 +0200] Configured for up to 100 clients.
I [15/Aug/2006:01:54:05 +0200] LoadPPDs: Wrote "/etc/cups/ppds.dat", 185 PPDs...
E [15/Aug/2006:01:56:36 +0200] IsAuthorized: pam_authenticate() returned Authentication failure)!

Then after changing the root password, it has:
I [15/Aug/2006:01:58:54 +0200] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=2067)

Before Printer setup, /var/log/cups/access_log has:
dslbox - - [15/Aug/2006:01:55:41 +0200] "GET / HTTP/1.1" 200 1604
dslbox - - [15/Aug/2006:01:55:42 +0200] "GET /cups.css HTTP/1.1" 200 87
dslbox - - [15/Aug/2006:01:55:42 +0200] "GET /images/navbar.gif HTTP/1.1" 200 2869

Running Printer setup added:
dslbox - - [15/Aug/2006:01:56:15 +0200] "GET /admin HTTP/1.1" 401 0
dslbox - root [15/Aug/2006:01:56:34 +0200] "GET /admin HTTP/1.1" 401 0

Running Printer Setup after running the "passwd" command:
dslbox - - [15/Aug/2006:01:58:42 +0200] "GET /admin HTTP/1.1" 401 0
dslbox - root [15/Aug/2006:01:58:54 +0200] "GET /admin HTTP/1.1" 200 0
dslbox - root [15/Aug/2006:01:58:54 +0200] "GET /admin HTTP/1.1" 200 2852
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/left.gif HTTP/1.1" 200 110
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/right.gif HTTP/1.1" 200 145
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/add-class.gif HTTP/1.1" 200 242
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/manage-classes.gif HTTP/1.1" 200 289
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/manage-jobs.gif HTTP/1.1" 200 266
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/add-printer.gif HTTP/1.1" 200 252
dslbox - root [15/Aug/2006:01:58:56 +0200] "GET /images/manage-printers.gif HTTP/1.1" 200 296

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

There is something odd with the /etc/passwd* files.

After booting with "dsl dma syslog secure base norestore" and entering the password
"cat#dog", then /etc/passwd and /etc/shadow are:

root@dslbox:/etc# ls -l passwd* shadow*
-rw-r--r-- 1 root root 1817 Jan 30 2006 passwd
-rw------- 1 root root 1792 Aug 14 21:07 passwd-
-rw-r----- 1 root root 1095 Aug 14 21:08 shadow
-rw------- 1 root root 1083 Aug 14 21:08 shadow-
root@dslbox:/etc# diff passwd passwd-
1c1
< root:$1$$I.X7vmLDEcVMmpJ9bU4Ar1:0:0:root:/root:/bin/bash
---
> root:x:0:0:root:/root:/bin/bash
root@dslbox:/etc# diff shadow shadow-
39c39
< dsl:ymunaU2gXsriI:13375:0:99999:7:::
---
> dsl:!:13178:0:99999:7:::

The older /etc/passwd file has the new password, while the newer /etc/passwd-
has the old null password.

Then, after running "passwd root":

root@dslbox:/etc# ls -l passwd* shadow*
-rw-r--r-- 1 root root 1817 Aug 14 21:12 passwd
-rw------- 1 root root 1817 Jan 30 2006 passwd-
-rw-r----- 1 root root 1095 Aug 14 21:08 shadow
-rw------- 1 root root 1083 Aug 14 21:08 shadow-
root@dslbox:/etc# diff passwd passwd-
1c1
< root:$1$$SFEVfR/HImkFczmLRUVs.0:0:0:root:/root:/bin/bash
---
> root:$1$$I.X7vmLDEcVMmpJ9bU4Ar1:0:0:root:/root:/bin/bash

Changing the password with "passwd root" again produces:

root@dslbox:/etc# ls -l passwd* shadow*
-rw-r--r-- 1 root root 1817 Aug 14 21:23 passwd
-rw------- 1 root root 1817 Aug 14 21:12 passwd-
-rw-r----- 1 root root 1095 Aug 14 21:08 shadow
-rw------- 1 root root 1083 Aug 14 21:08 shadow-
root@dslbox:/etc# diff passwd passwd-
1c1
< root:$1$$U1X9vWnfWS.odMsv3JpAA/:0:0:root:/root:/bin/bash
---
> root:$1$$SFEVfR/HImkFczmLRUVs.0:0:0:root:/root:/bin/bash

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

I think that this post might actually be useful!

The "secure" boot cheatcode only updates the /etc/shadow and /etc/shadow- files.

The "passwd" command only updates the /etc/passwd and /etc/passwd- files.

I know that this isn't dsl, but...

with dsl, both the secure cheatcode and the passwd command only update the shadow files.

Yet, cups (or is it pam) is using the password that is in the /etc/passwd file.

roberts · Joined: 17 Apr 2006 Posts: 320 Location: OC CA USA

Good analysis.
I believe the issue is with the chpasswd program.
This works fine with DSL but apparently not DSL-N.
I suppose if you try changing the password using the non-interactive /usr/sbin/chpasswd you will have the same results.

rja · Joined: 20 Apr 2006 Posts: 21 Location: Chicago, IL USA

Running /usr/sbin/chpasswd updates the /etc/shadow file, and doesn't
touch /etc/passwd.

So, /usr/sbin/chpasswd does the same thing as the "secure" boot cheatcode.

/usr/bin/passwd and cups (which is calling pam-authenticate()) are using /etc/passwd instead of /etc/shadow.

All of the above was run under dsl-n.

Another difference with dsl-3.0.1 is that the group id for /etc/shadow is "shadow" while the group id for dsl-n is "root". Changing the group id for dsl-n didn't seem to help. cups would still only use the /etc/passwd file and ignore the /etc/shadow file.

roberts · Joined: 17 Apr 2006 Posts: 320 Location: OC CA USA

Found the problem. Fixed it. Will likely issue RC4 very soon now.
Thanks for the feedback.