Changing UID/GID

[Suren Selva]

Hello All,

I am in the process of planning a re-alignment of UIDs & GIDs of non administrative and non system users. I have these questions:

1. Is UID/GID re-alignment a "safe" change to do? i.e can it be done successfully without compromising the system?

2. After using SAM to change the UID of a user, I find that there are still some files and links with the old UID in the system. How can I also change soft links without changing the UID of the target it is pointing to using find?

3. Does anyone have a good ideas and suggestions to do this change?

All replies are appreciated. Thank you.

Regards,
Suren Selva

[Hai Nguyen_1]

Suren,

If you have lots of users, you better save the original /etc/passwd and /etc/group just in case.

Hai

[Hai Nguyen_1]

One more thing I have just thougt of is doing this in single user mode and then bringing up the system to multi-user mode for system consistency in term of changes in uid, gid.

Hai

[Leif Halvarsson_2 · Accepted solution]

Hi
To change the symbolic links

find . -type l -user xxx -exec chown -h yyy {} \;

[Daimian Woznick]

I would script this if at all possible. First you will need to identify which accounts will change. Then take one account at a time. Find all the files owned by that user and place the list in a temporary file. Next change the UID and then go back and change all the files that are owned by the old UID to the new UID (done with a loop on the list). You will have problems with the symbolic links because they will not change. You can either ignore this or remove and create the link again with the new UID.

Now your question on this all being safe. I would not do this on a server that is being used. Do this while the users are all tucked in and sleeping sound. This is also not very fun on large servers where the find itself will take close to an hour.

Hope this helps.

[Jordan Bean]

Safe? Sure. Just don't mess with system accounts.

Caution: I have not performed this procedure. Experts, please advise.

Make a backup of /etc/passwd and /etc/group.
Make a backup of the entire system.

Do this in single user mode with all necessary filesystems mounted.

Create an ownwership manifest of files in all shared directories. (See attached PERL script.) Avoid system and top level directories.

find /dir1 /dir2 -xdev | manifest.pl > manifest.out

Do not modify /etc/passwd directly. Use the usermod utility as it will modify the ownership of home directories automatically.

Using a new passwd-formatted file of ONLY changed user accounts as input:

#!/sbin/sh
# one-by-one, change users' id numbers
while IFS=':' read name pw uid junk
do
#change user's uid
if usermod -u $uid -o $name
then
# recursive update of home directory
# and mail spool ownership, for good measure.
# the eval correctly resolves ~$name
eval chown -hR $name ~$name /var/mail/$name
fi
done < new-passwd-file


The -o option to usermod accounts for the likely overlap of userid numbers during the run.

The -h option to chown will modify ownership
of symbolic links, not the target files.

Now update ownership of all files in the previously created manifest:

#!/sbin/sh
while read name file
do
chown -h $name "$file"
done < manifest.out

To verify, create a new manifest and compare.

Did I miss anything?

[Suren Selva]

I changed a uid using SAM. SAM did not change the uid of all the files owned by the user. It left some of the users files with the old uid. Does anyone know why it does that?

SAM also left some softlinks with the old uid. The samlog_viewer showed chown being used instead of chown -h. This means that if the links are owned by the user, the links themselves won't be changed, but the target the links point to will be changed even if they are NOT owned by the user. Suppose user peterj has a link called peterlink that points to target /sbin/init, the ownership of peterlink will not change but /sbin/init will. Isn't this dangerous? Any opinions? Thanks.

Suren

[doug hosking]

I agree that this is rather messy, and isn't
something I'd likely do on a system without
some really compelling reason. In addition to things already mentioned, keep in mind
that

1) you may have to do similar changes on
other systems if you share files with NFS,
use NIS for passwd file management, etc.

2) The maximum value of a uid varies between HP-UX releases. If you have a mix of newer
and older releases AND try to use large
uids, you could wind up with a situation
like this where the uid is silently truncated:

# touch /tmp/foo
# chown 1234567 /tmp/foo
# ll /tmp/foo
-rw-rw-rw- 1 54919 sys 0 Aug 2 09:59 /tmp/foo
#

(54919 is 1234567 modulo 65536)

If I remember correctly, HP-UX 10.20 was the
first release to support 32-bit uids.

Even on newer HP-UX releases you can't always use the full 32 bits of uid. See the edquota manual page for restrictions. Usually this isn't an issue but you wouldn't want to be surprised by this during/after a long conversion!

3) There can be 'hidden' uids. For example, if you have something in 'ar' format, the saved
uid/gid of the files in the archive won't be
changed by your chown. Depending on which
backup utilities you use, there could be similar problems with restoring backup tapes

4) HP-UX thinks it owns the low-numbered
uids and gids. Please reserve (at least)
the first 100 or so uids for system accounts
like bin, lp, adm, etc. and don't change
the values of the existing system IDs.

There are probably other issues, but these
come to mind as things you would want to
consider before attempting such a conversion.