passwd: not allowed to run passwd

[Dan Corrin]

I have a 10.20 system in trusted mode. I run into this problem for most users on the
system, running passwd as root.
I am aware that root has a problem with overriding the u_pswduser= flag on 10.20 systems, and the default entry seems normal.
An example of an entry is:
sys:u_name=sys:u_id#3:\
:u_pwd=*:\
:u_auditid#3:\
:u_auditflag#1:\
:u_unsucchg#1086019826:u_suclog#890421064:u_lock@:\
:chkent:
root@ecdev105:/tcb/files/auth/s# passwd sys
Last successful password change for sys: NEVER
Last unsuccessful password change for sys: Mon May 31 12:10:26 2004

passwd: not allowed to run passwd

[Ralf Seefeldt]

Hello,

I'm not sure, if this will help. I have found some note about passwordaging in my notes:

Setting Password restrictions w/o a trusted system , HP/UX, trusted system
Before the invention of trusted systems you could put a letter and number combination in your password file. Thi still works today. I managed to fin this in old HP
System Admin Student Workbook. At the end of the encrypted password you add ,char1char2 char1 is the maximum number of weeks the password is valid and
char2 is the minimum number of weeks that must pass before the password can be changed. The following is a good guide: Value # of weeks
. 0
/ 1
0-9 2-11
A-Z 12-37
a-z 38-63
so for example if you wanted a user to change their password somewhere between 11 and 2 weeks you would put ,A9. (man 4 passwd)

May be, this gives you some idea wher to look for the problem.

Bye
Ralf

[Joseph Loo]

hi,

just like to confirm the permission of passwd:

# ll /usr/bin/passwd
-r-sr-xr-x 5 root bin
^
/|\
|

it should have SUID bit set.

regards.

[Dan Corrin]

In reply to Joseph Loo, I am trying to run the passwd command as root, but in any case it is suid root.
-r-sr-xr-x 1 root bin 86016 Mar 3 1997 /bin/passwd

I have attached my /tcb/files/auth/system/default file in case that has any bearing...

Just to clairify, this affects every account on the system, I chose sys for the example as it is a clean/simple entry.

[Christopher Caldwell]

I've seen this before when the tcb became corrupt. Try pwck and authck, to see if you can spot the issue.

[Dan Corrin]

Thanks to Christopher Caldwell, but it didn't help. Running pwck shows a few missing home directories, and authck just verifies my problem: (I also tried deleting pw_id_map so it was re-created, turning auditing off).

root@ecdev105:/# authck -p -v
finding all entries in the Protected Password database, in /tcb/files/auth

Checking format of files in Protected Password database /tcb/files/auth
finding all entries in the Protected Password database, in /tcb/files/auth
Format of all Protected Password entries OK

Checking Protected Password against getprpwent()

Checking Protected Password against /etc/passwd

Checking Protected Password fields against those in /etc/passwd

Checking internal consistency of Protected Password fields
root cannot have a password set on the account
daemon cannot have a password set on the account
bin cannot have a password set on the account
sys cannot have a password set on the account
adm cannot have a password set on the account
etc.
(If only it would say why...)

[Paula J Frazer-Campbell]

Hi

Three options:-

1. Check patch levels.
2. Turn off and then back on trusted mode.
3. Upgrade to ver 11 (10.20) is now not supported.

Did this ever work and if so what has changed?

Paula

[Sridhar Bhaskarla]

Hi,

Can you post the contents of /tcb/files/auth/system/default? I believe this file might have gotten corrupted.

-Sri

[Dan Corrin]

In response to Sridhar Bhaskarla, the default file was already posted earlier.

[Dan Corrin]

Okay, I have the solution. It was, as supposed, the default file that was the problem, the entry u_pickpw was missing.
After converting to untrusted and back again, passwd started working, so I traced the problem back to the default file, and added in entries one at a time to the original until it worked.

[Daryl Much]

for the record: I had similar problem and authck -pv gave lots of errors re: user cannot have a password set on the account. I checked the /tcb/files/auth/system/default file and the u_pswduser entry had a user listed that did not exist (hmm...). Changing value to root fixed it.

Regards,

Chuck Davis

[Jack C. Mahaffey]

I had a similar problem and I traced it back to a directory in /var/spool/cron/crontabs that needed to be deleted. I had created a directory named 'backup' in the past to hold previous crontab files. When I converted to trusted it did display an error about the conversion failing but it looked like trusted security was really working. All the dialogs worked ok. When I ran authck -p every entry in /etc/passwd had the "cannot change password" message.

I went back into the sam log and noticed the problem lied with the /var/spool/cron/crontabs/backup directory. I then untrusted the system, removed /var/spool/cron/crontabs/backup and then trusted the system with no errors.

I was fortunate to do this testing on a non-production server.

authck -p now returns no errors.