I have been given a list of accounts on a Solaris 11 server that contains several accounts which are prefixed with a # character: "#username". (No LDAP is being used, and all accounts are local Solaris server accounts.)

The server admin has told me that Solaris accounts prefixed with # cannot be used to login. I have tried to find some documentation to back-up this claim, but I have only found https://forums.gentoo.org/viewtopic-t-513008.html where a contributor wrote that prefixing a line in etc/passwd would result in an account which has # as the first character. (The discussion is from 2005 and it isn't clear whether it is related to Solaris, or some other Unix-based/derived OS.)

So can a Solaris account prefixed with # be used to login, or will the OS prevent a successful login?


3 Answers 3


According to the passwd(5) manual, a username starting with a character other than a alphabetic one should generate a warning (presumably when the passwd database is accessed).

It's possible that your admin relies on the fact that the entries for users that should not be allowed to log in are simply malformed (note that there is no facility to comment out lines in the passwd file).

I would suggest that instead of relying on malformed entries, users that should not be allowed to log in are properly restricted using passwd -N username instead (see passwd(1)), or through some similar mechanics. Or possibly just deleted, if the users should not exist on the system.

  • 2
    Exactly what I was thinking, commenting out passwd entries is not exactly the best sysop strategy I can think of. Commented Feb 20, 2019 at 13:03
  • @RuiFRibeiro Also, the file format does not allow for comments.
    – Kusalananda
    Commented Feb 20, 2019 at 13:04
  • 3
    (I know, I was just being polite) Commented Feb 20, 2019 at 13:04
  • passwd -N <username> just removes the password. Users can still log in via other methods (such as ssh keys). passwd -l <username> locks the account, and as long as the default PAM configurations haven't been changed, should prevent a user from being able to log in by any means. Commented Feb 27, 2019 at 17:13

Yes, password tables can contain comments …

… but not on Illumos, OpenBSD, or Linux; and only in the source form. The people writing on the Gentoo Linux WWW site had not experienced a wide enough range of operating systems.

The file format is not the same across all operating systems. FreeBSD, reading the /etc/master.passwd file, allows for line comments. The Linux, OpenBSD, and Illumos parsers for their /etc/passwd or /etc/master.passwd files do not.

As you can see, the first few lines of the initial FreeBSD /etc/master.passwd file are comment lines, which are explicitly ignored by the FreeBSD pw_mkdb program. The OpenBSD pw_mkdb lacks this, and its default /etc/master.passwd has no comments.

Of course, once the pw_mkdb program has compiled the source into the actual database that is used by the library routines that look up things in the system account database, the comments have been filtered out. The actual compiled database format is Berkeley DB, which does not have comments.

The Linux user account database subsystem does not use compiled database files with indexes, unlike the BSDs. Its lookup library routines, parsing the original flat tables, do not allow for comments, though. The same is true for Illumos, and for OpenSolaris before it.

No, user names cannot practically contain # characters.

POSIX specifies that a portable account name can only comprise characters from the so-called Portable Filename Character Set, with an additional restriction on the first character of the name. This set does not contain the # character.

The additional restriction on the first character is important, because it touches upon the reasons that # will cause problems in account names. Account names are used as arguments to programs, and arguments beginning with - generally denote option arguments. (Yes, there are ways to avoid account names from being treated as option arguments, but they are not universal nor standardized.)

This is the nub of the problem. Although the actual source form of the table itself allows any character other than the field separator (), record separator (:), or (on FreeBSD) the end-of-line comment introducer (#) in the first field of a record, the use of account names in a large number of other contexts places a lot more constraints upon them:

  • The C library routines treat these fields as -terminated strings, so they cannot contain the character.
  • Account names are used as command arguments, as mentioned, not least as arguments passed from getty programs to login in old-style operating systems. (Illumos is in the family of Unices that got rid of the getty program back in 1988, of course.) This rules out the character and initial -.
  • Account names are configured in shell scripts (or approximations thereto) using variable assignments, from settings in /etc/rc.conf to /etc/sysconfig/wibble, so shell metacharacters that would break such scripts are not used. So #, being a shell metacharacter, is not used.
  • Account names are held in environment and shell variables. So characters such as the character and = (which causes ambiguity in parsing process environments) are not used.
  • Account names are configured in .INI files, so metacharacters for .INI files, including =, #, and ; are not used.
  • … and so on.

So although using # does not comment things out in the password file on Illumos, its use would cause a fair number of problems elsewhere.

For special account names, use …

… the FreeBSD convention of an initial _, something like the Debian convention of a Debian- prefix, or the Daniel J. Bernstein convention of an initial uppercase G.

For locking out accounts, use …

… the correct field of the record in the first place! It isn't the name field. It is the password field, which on Illumos contains special values for locked and no-login accounts.


The Solaris 11 passwd man page states:


is the user's login name.

The login (login) and role (role) fields accept a string of no more than eight bytes consisting of characters from the set of alphabetic characters, numeric characters, period (.), underscore (_), and hyphen (-). The first character should be alphabetic and the field should contain at least one lower case alphabetic character. A warning message is displayed if these restrictions are not met.

Note that there is no documentation there stating that a username starting with a # will not be allowed to log on.

Relying on such accounts not being allowed to log in, in the absence of documentation supporting such behavior, in such a security-related context, is not what I would call the behavior of a competent system administrator.

Your system administrator is hoping that such behavior continues in the future. Hoping is an awfully low standard to pin security restrictions on.

You must log in to answer this question.

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