5

As much as I would like to figure out the problem, at this point too much time has been invested in deleting a stupid key when I already had a solution (the command line creation) that works. I'm going to delete the user and run the commands that I need. It would still be wonderful to have an answer, but I don't think that is going to happen.

I have a network of slaves attached to buildbot, each with a buildbot user account. I'd like their accounts to not have passwords (read: not an empty password). I did this successfully on one of the boxes as a great consequence of remotely creating the user and not setting the password in the procedure.

Two other OSX machines that I set up through the GUI do have passwords, and I'm wondering if there is a way to remove the password without leaving it empty. I looked through a bit of the documentation for dscl and passwd, but they don't have the options I'm looking for. I could set them to be some random string of numbers. Would that be just as effective? Is my description equivalent to having an empty password and locking the account (as in this disscussion for linux)? If so, how do I lock an OSX account?

The second part of my question is in regard to the way that I originally created the users. Below are the commands and they seem to work fine but I wonder if I'm missing some important setting --the buildslave did start and execute jobs though.

sudo dscl . -create /Users/buildbot
sudo dscl . -create /Users/buildbot UserShell /bin/bash
sudo dscl . -create /Users/buildbot RealName "BuildBot"
sudo dscl . -create /Users/buildbot UniqueID <ID>
sudo dscl . -create /Users/buildbot PrimaryGroupID 61
sudo dscl . -create /Users/buildbot NFSHomeDirectory /Users/buildbot
sudo mkdir /Users/buildbot
sudo chown buildbot /Users/buildbot

EDIT: For the machines that already had accounts w/ passwords created through the System Preferences, the commands suggested by Dan Black do not actually delete the Password key,

sudo dscl . -delete /Users/buildbot Password
sudo dscl . -read /Users/buildbot Password

The output to the second command is,

Password: *******

Continuing as if the password was deleted, I run

sudo dscl . -create /Users/buildbot Password '*'
su buildbot

And the previous password accesses the account. This is on OSX 10.5.8 and 10.6.8.

sudo dscl . -change /Users/buildbot Password 'OLDPASS' '*'
su buildbot

This also does not change the password, and OLDPASS can switch users when asked for the password.

Here is the complete key-value pair output for the user i'm having trouble with --created through sys-preferences. To clarify an inconsistency, this machine uses user 'developer' not 'buildbot', but the previous commands were all done the same just with the obvious replacement

Amoy:~ lyn$ sudo dscl . -read /Users/developer
dsAttrTypeNative:_writers_hint: developer
dsAttrTypeNative:_writers_jpegphoto: developer
dsAttrTypeNative:_writers_LinkedIdentity: developer
dsAttrTypeNative:_writers_passwd: developer
dsAttrTypeNative:_writers_picture: developer
dsAttrTypeNative:_writers_realname: developer
dsAttrTypeNative:_writers_UserCertificate: developer
AppleMetaNodeLocation: /Local/Default
AuthenticationAuthority: ;ShadowHash; ;Kerberosv5;;developer@LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;LKDC:SHA1.08FF6FDC52096FD6C53DEDEE75A2F9315F964B22;
AuthenticationHint:
 developer for auto testing
GeneratedUID: BF95A834-A7F1-4DDD-8DFB-6B80B8120CA7
NFSHomeDirectory: /Users/developer
Password: ********
Picture:
 /Library/User Pictures/Fun/Flippers.tif
PrimaryGroupID: 20
RealName: Developer
RecordName: developer
RecordType: dsRecTypeStandard:Users
UniqueID: 512
UserShell: /bin/bash
12
  • I'm confused: you want them to not have a password, but not have a blank password? Jan 10, 2012 at 16:30
  • yeah. I guess the same affect may be having a blank password and locking the account? (from looking around,unix.stackexchange.com/questions/7283/…). Would this be correct?
    – nlucaroni
    Jan 10, 2012 at 16:41
  • That looks right, but I didn't quite understand your question based on wording alone. I would recommend editing it to say so, and if that is the answer, paste what was said and give credit as an answer Jan 10, 2012 at 17:27
  • No it's not right for OSX; passwd -l is for location not lock. I edited the question accordingly. Does it need further clarification? I thought I was being pretty precise.
    – nlucaroni
    Jan 10, 2012 at 17:34
  • My confusion came from your second sentance, that's all. And the OSX part is what drew me in, but I don't use dscl to make users, I use the GUI part Jan 10, 2012 at 17:45

2 Answers 2

2

I think the problem you're having with @Daniel Beck's answer is that the password isn't stored in the user record's Password attribute, but as a shadow hash file in /var/db/shadow/hash/USERGUID, and the AuthenticationAuthority attribute still points to that. This seems to work for me:

sudo dscl . -delete /Users/buildbot AuthenticationAuthority
buildbotGUID=$(dscl . -read /Users/buildbot GeneratedUID | awk '{print $2}')
sudo rm "/var/db/shadow/hash/$buildbotGUID" "/var/db/shadow/hash/$buildbotGUID.state"

Ideally, you should also remove the account's Kerberos principal (OS X clients run their own "local" Kerberos realm, and it occasionally gets underfoot). But that's a bit more complicated, and I think depends a fair bit on which version of OS X you're using.

BTW, if the above doesn't completely do the trick, try this:

sudo dscl . -create /Users/buildbot AuthenticationAuthority ";DisabledUser;"
2
  • Disabling the account is functionally equivalent to locking it?
    – nlucaroni
    Jan 11, 2012 at 0:24
  • Mostly; there are probably some subtle differences. Note that the "disabled" setting is in the AuthenticationAuthority attribute, so generally it only disables authentication, not other account functions. I don't know enough about buildbot to know this will interfere with it. Jan 11, 2012 at 1:10
3

You need to set the password to a single * character (asterisk, star) using dscl.

sudo dscl . -create /Users/buildbot Password '*'

Be sure to escape or quote (as shown) it so it doesn't get interpreted by your shell.

This will (when read) not be displayed as ******** like any other password, but as *, which just means "no password".

12
  • It's probably derived from the use of a * in passwd files that only contain password hashes to indicate that a user has no password.
    – Daniel Beck
    Jan 10, 2012 at 18:10
  • This did not update the password; after executing the command I can still use the old password. is it possible that it should be -change instead of -create?
    – nlucaroni
    Jan 10, 2012 at 18:20
  • 1
    @nlucaroni Did you -delete /Users/buildbot Password before executing that line? My reference starting point was the code in your question, which didn't mention creation of a password.
    – Daniel Beck
    Jan 10, 2012 at 18:21
  • No, I did not delete anything; I thought you were referring to my earlier made accounts. Do I have to do this to the newly created account through the command line? It appears to be doing what I want without setting that key at all.
    – nlucaroni
    Jan 10, 2012 at 18:24
  • @nlucaroni Now I understand what you mean. It's difficult with multiple questions combined into one. Run dscl with the arguments in my earlier comment first to delete the old password, then set the new one to '*'. -change might work, I haven't tested it myself though. What do you mean by without setting that key at all? What's the output of dscl . -read /Users/buildbot Password?
    – Daniel Beck
    Jan 10, 2012 at 18:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .