Opened 20 years ago

Closed 20 years ago

Last modified 20 years ago

#2821 closed defect (worksforme)

[PATCH] Add AuthenticationAuthority field to users created via adduser

Reported by: jberry@… Owned by: olegb@…
Priority: Normal Milestone:
Component: base Version: 1.0
Keywords: Cc: snu@…
Port:

Description

Patch attached.

This patch adds the AuthenticationAuthority: ;ShadowHash; field to users created via adduser. Without this field, routines such as getpwnam will fail (on 10.3.x anyway) for the given user as they expect the user information to be in the /etc/passwd file, which it is not.

I encountered this error while attempting to beef-up the port for dovecot. It fails at startup if the user created by adduser doesn't add AuthenticationAuthority: ;ShadowHash;

Attachments (1)

portutil.tcl.diff (1.1 KB) - added by jberry@… 20 years ago.
Patch to base/src/portutil.tcl

Download all attachments as: .zip

Change History (8)

Changed 20 years ago by jberry@…

Attachment: portutil.tcl.diff added

Patch to base/src/portutil.tcl

comment:1 Changed 20 years ago by snu@…

Wouldn't ;basic; be more correct, unless you're going to create the shadow hash file.

comment:2 Changed 20 years ago by snu@…

Owner: changed from darwinports-bugs@… to olegb@…

ole seems to have taken this from his comments on the darwinports@ list

comment:3 Changed 20 years ago by snu@…

Cc: snu@… added

comment:4 Changed 20 years ago by snu@…

Oh, and it should be authentication_authority as well.

And actually I don't see why this is needed at all anyway.

comment:5 Changed 20 years ago by snu@…

Resolution: worksforme
Status: newclosed

Yup, I have tested and the assertion that getpwnam fails for users without an authentication authority is just plain incorrect (Mac OS X v10.3.8, doubt it's changed recently)

comment:6 Changed 20 years ago by jberry@…

Honest, I didn't just make this patch for the hell of it. I don't have that much time.

That said, I can no longer reproduce the problem, so maybe there was some other "issue" with my ds. (There have been long-standing reports of wierd sync issues in creating users; maybe this was one of those.).

All I know is that getpwnam was failing for the newly added user until I added the AuthenticationAuthority property.

By the way, snu, I used "AuthenticationAuthority" based on the man page for getpwnam, and based also on the fact that that's the property name used in all the other user records on my system, created by the system. I quote the man page:

As of Mac OS X 10.3, there are now different per-user behaviours of this function, based on the AuthenticationAuthority value stored for the queried user in DirectoryServices.

If the queried user is still a legacy crypt password user or now has an AuthenticationAuthority value containing ;basic;, these routines will behave in their standard BSD fashion. These functions will shadow the password file, e.g. allow only certain programs to have access to the encrypted password. If the process which calls them has an effective uid of 0, the encrypted password will be returned, otherwise, the password field of the returned structure will point to the string `*'.

By default in Mac OS X 10.3 and later all users will have an Authentica- tionAuthority will contiain the value ;ShadowHash;. These users will have a visible password value of . These functions will have no access to the encrypted password whatsoever. Setting or changing an user password must be done entirely through the DirectoryService APIs for this default user.

Not particularly clear. Based on the clarity of that statement, however, perhaps I guessed wrong about the value to use. I based the value ";ShadowHash;" on the fact that the records created by the system use that value (and that property name), and there is no shadow file.

But since I can no longer reproduce the problem, I'll retract the bug report for now, pending any other complaints.

-jdb

comment:7 Changed 20 years ago by jberry@…

Reports of other wierd behavior with adduser at bug #2050.

Note: See TracTickets for help on using tickets.