Limitation of eight characters for user names

[Jerome D'silva]

Hi all,
The HPUX 11.0 has a restriction of user names being not more than eight characters .Can this limitation be overcome and how? .In HPUX 10.2 , I used to edit the /etc/passwd file and modify the user names to more than eight characters , but in 11.0 that doesnot seem to work .Please provide your vaulable suggesstions on the same.

Thanks
Jerome

[Christian Gebhardt]

Hi

I've tested it and I think it works:

# su - c1234567890
# id
uid=550(c1234567890) gid=20(users)

Do you have trusted system ?? Then it is not so easy to change username in /etc/passwd, you have to do a lot more.

Chris

[Steve Steel]

Hi

HP aims to stick to standards and that is 8 characters. However it would appear that from PHCO_21833 a libpam patch you can use a long usernames workaround.

From PHCO_21833 :libpam:login:trusted:

libpam_unix.1 now checks for the existence of a file in the "/etc/default" directory called:
"I_ACCEPT_RESPONSIBILITY_FOR_BYPASSING_SECURITY_CHECKS".
If this file exists, then login names longer than 8 characters can be added to /etc/passwd, and then those users can login.
Note the following restrictions:
1) HP has never claimed that HP-UX supports user names
longer than 8 characters, and does not recommend that
customers bypass the existing length checks. Doing
so may cause functional and/or security problems.
2) This patch does not remove the existing user name
length checks from other commands - e.g. pwck(1m),
sam(1m), useradd(1m).
3) Do not enable long usernames on trusted system
configurations.


Steve Steel

[Robert-Jan Goossens]

Hi Jerome,

check this patch

-Qoute-
PHCO_21833:
(SR: 8606135483 CR: JAGad04617)
The PAM libraries are intentionally designed to not allow
login names longer than 8 characters. Some users want a way
to bypass this restriction, even though doing so causes PAM
to bypass some security checks and may cause some commands
to function incorrectly.

-Unquote-

http://www5.itrc.hp.com/service/patch/patchDetail.do?patchid=PHCO_26089&context=hpux:800:11:00

Hope it helps,

Robert-Jan.

[Bill Hassell]

All 'standard' Unix flavors are limited to 8 character usernames. The request for longer usernames always comes from attempting to make unrelated operating systems try to work together (ie, Windows-something). Yes, you can add the patch mentioned and set the long filename (which is designed to remind you of unknown cosequences), but sysadmins for this system will have a permanent job in tracking down problems related to this non-standard situation. The worst consequence is for security--PAM is the underlying authentication mechanism for HP-UX starting with 11.00 and will be the standard for future releases. Using long user ID's will create lots of problems in the future as you increase the level of security on your system.

[Steven E. Protter]

I think you can set up your server as an LDAP server and then support longer names. It is a lot of work.

You can connect to a Microsoft or other LDAP server that supports longer user names and let that server handle authentication onto your box.

The Internet Security Class has a cookbook for setting that up.

If you are interested in LDAP as an option, I've got a hard copy of an HP White paper I can look at, then do an internet search and try and get you a link.

I'm not going to go further unless you indicate an LDAP implementation interests you.

P

[Frank Slootweg]

I do not know if that is the case here, but often when people ask for long(er) user names, they really only 'need' long(er) *email adresses*. A long e-mail address is no problem whatsoever, because it only affects the mail portion(s) of the system.

[doug hosking]

Steven, LDAP really can't solve this problem. It's a lot more complicated than it sounds. Too much ancient code has hard-coded arrays of 8 or 9 bytes when dealing with user names, or hidden assumptions about the length. Some of these arrays are, unfortunately, embedded in other structures. Authentication is by no means the only part of the system that's affected by this. Even a cursory study of the potential impacts shows a lot of problems that would have to be overcome. Doing so without breaking compatibility with existing applications is very difficult at best, and in some cases essentially impossible.

HP is very much aware of the need for support of longer user names and trying hard to find a good solution, but this is absolutely not something that is reasonable to patch into an existing OS release because the impacts are so pervasive.

As for the PAM patch, the warnings are there for very good reasons. Ignore them at your own risk.

[Jerome D'silva]

The description of the patch says that it shouldnot be done on a trusted system . Mine is a trusted system. Can I go ahead / what repercussions it might have?

Thanks
Jerome

[Darren Prior]

Hi,

I'd strongly advise against removing the 8 char user name restriction anyway, but as this is a trusted system you can't use the I_ACCEPT_RESPONSIBILITY... method. You can install the patch on a trusted system - it has many other features that are useful on trusted systems.

What repercussions might it have if you do go ahead? Well, as HP have made it clear that it should not be performed on a trusted system you would be operating in an unsupported configuration. Please re-read the restrictions again.

regards,

Darren.

[T G Manikandan]

The patch clearly states that this patch should not be installed on trusted systems.

On non-trusted systems you are bypassing security checks using the patch which enables username > 8 charac.
A system is converted to trusted from non-trusted to keep it more secure.

If you are to install that patch on trusted system then the username length problem will be resolved but you are making yourselves into trouble.

Follow THE HP WAY

[doug hosking]

This isn't just a matter of security, but one of functional correctness and system integrity. The data structures used by trusted systems simply don't have sufficient space for the longer names. No amount of wishing will change that. If you overflow those fields by disabling the security checks, you will overwrite AND CORRUPT truly critical other information.

As one really simple example of how things break:
Start from a system in standard mode.
Create a user called 'whydidyoucheat'
Run /usr/lbin/tsconvert to convert to
a trusted system. Note that authck is now
quite upset about the state of the system:
$ authck -p
whydidyoucheat appears in /etc/passwd but not in Protected Password database
whydidyouche??6??* not listed in /etc/passwd nor the Nis+ passwd table, but is in the Protected Password database.

This is only ONE of the more glaring examples of failure. There are many other, more subtle ones that can have major impact on the integrity of your system, much less the security of it.

Again, the warnings aren't there to be mean. They're not there to scare people into buying something. They're there because they are NEEDED and there is no practical patch that will take away that need. I don't know how much more clearly this can be said.