by hankivy » Jul 10th, '15, 06:06
Status:
1. My existing normal user ids, for people, are assigned 500, and higher.
And system level users have ids that are 499 or lower.
2. The newer versions of Linux are assigning normal user ids starting at 1000.
And system level users have ids that are 999 or lower.
3. There are system level utilities coming that need more and more system level user ids.
How system users start running in the system, or own files, etc. are beyond the scope of this document.
4. A similar issue exists for the group ids.
5. Any online upgrade will try to preserve my normal user ids.
So: Today, I am NOT forced to move my user ids.
I could move now, wait until I choose to move ids, or wait until I am forced to move.
But I think I will try to move before I upgrade to MAGEIA 5.
----
For only a few users, I would do the process manually.
For a lot of users, or a lot of systems, I would write a script in a language like PERL.
----
DETAILED PLAN FOR A MOVE:
Warning: This plan assumes that all normal user names with ids 500-999, have unique names, and unique ids.
It assumes that all of the corresponding default groups also have unique names, and unique ids that need to be changed.
At this point, my college textbooks would say, "Extending the plan is left as an exercise for the reader."
1. Open a Terminal window, switch/login as the root user.
2. Backup the /etc/passwd, and /etc/group files.
# cd /etc
# cp passwd passwd.orig
# cp group group.orig
3. Create new users and groups (with ids >=1000) to later swap with the existing users, with ids < 1000.
-- Repeat the following two commands, substituting your user/group names for hank, and unused ids for 1000.
-- My user name is hank, user id is 500, default group id is 500.
-- The new user will not have a home directory, and has a disabled password,
-- and the default shell would echo a warning message prior to terminating, and a new group.
-- There is defense in depth here to make this user id useless.
-- More later on why and how to use it.
-- Because of the password state, neither a normal login, nor an ftp login, nor an ssh login with password will succeed.
-- Because of the lack of a home directory, an ssh login will fail public key authentication, i.e. fail login.
-- Since the default shell is a restricted shell, any successful login will echo an error message and terminate.
-- I hope MSEC will not mind.
# groupadd -g 1000 hank-old
# adduser --home /dev/null --gid hank-old --uid 1000 --no-log-init -M -N --shell /sbin/nologin hank-old
-- NOTE: By default the new user's password is disabled.
-- NOTE: By using two commands, I control the ids of the user and the group regardless of current system defaults.
4. Again backup the /etc/passwd, and /etc/group files.
# cp passwd passwd.new
# cp group group.new
5. Shut down the system.
6. Using a Mageia live DVD, boot the system on the DVD.
7. Mount the hard drive file systems. Backup the hard drive file systems.
8. Edit the group ids.
# vim /mnt/.../etc/group
[hank is otherwise correct but 500 should become 1000.
hank-old is otherwise correct but 1000 should become 500.]
-- Repeat as needed.
9. Edit the passwd file's user ids.
# vim /mnt/.../etc/passwd
[hank is otherwise correct but both 500 should become 1000.
hank-old is otherwise correct but both 1000 should become 500.]
-- Repeat as needed.
10. Again backup the /etc/passwd, and /etc/group files.
# cd /mnt/.../etc
# cp passwd passwd.final
# cp group group.final
11. Change the ownership and group ids in the file systems on the hard drives.
[The first command is for user id numbers, second for group ids.]
$ sudo find /mnt/.../home -uid 500 -exec sudo chown -h 1000 {} \;
$ sudo find /mnt/.../home -gid 500 -exec sudo chgrp -h 1000 {} \;
[The sudo's are not needed if it is being run by the root user.
Repeat both commands for the other file systems.
Repeat all of those for all of the other user ids and group ids as needed.]
[ASIDE: If I were the admin of a lot of systems, with a lot of user ids 500-999,
I would write three non-shell scripts to automate this.
The first, for steps 2-4, would analyse the group and passwd file,
then build a data file with the matching old and new groups/users,
then create all of the new groups/users.
It would validate the new ids, and names, and automate the creation.
The second would automate steps 8, 9, and 10.
The third, for step 11, would search the file systems, and change the uid/gid of the files itself.
It would scan each file system once, and only once; not twice for each changed user.
It would never fork, not twice for each file owned by a changed user.]
12. Shutdown the live system, and reboot from the hard drives.
New Status -
Any backups, thumb drives, tar files, etc. that contain a file owned by 500 are owned by hank-old.
Administrators would know the person that had owned the file. Any files in a folder or thumb drive
could be dealt with individually, or all together by repeating step 11 above.
When ever the *-old groups and user ids are no longer needed to support or explain backup files,
then they can be deleted.
-- There is only one way I know to run a shell with the user id for hank-old.
$ sudo su --preserve-environment hank-old
-- HOME, SHELL, USER and LOGNAME are as before the command.
-- The shell that is running will be the same as the shell when the sudo command was started.
-- This is useful to change permissions, ownership, read, or write files owned by hank-old.