[PATCH] Add AuthenticationAuthority field to users created via adduser

[jberry@…]

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;

[jberry@…]

Patch to base/src/portutil.tcl

[snu@…]

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

[snu@…]

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

[snu@…]

Oh, and it should be authentication_authority as well.

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

[snu@…]

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)

[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

[jberry@…]

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