系统管理员工具包: 更改 UID 和 GID

更改 IBM® AIX® 操作系统中的用户标识号 (UID) 和组标识号 (GID) 对于 UNIX® 管理员而言是件枯燥无味的事情之一。尽管这通常是让人望而生畏的任务，但这是管理员为保持环境中系统同步所必须执行的一项基本工作。由于更改 UID 和 GID 可能会对您的环境造成严重损害，因此必须非常小心。最重要的是要了解进行哪些更改。然后才能知道如何进行正确的更改，甚至可以使用 UNIX 脚本自动执行更改流程。

UID 和 GID：一些背景知识

AIX 中的文件所有权是由 UID 确定的，组文件权限是由 GID 确定的。UID 和 GID 是范围从 0 到大约 65,535 的一些整数（此数字因您使用的 UNIX 版本而异）。每个用户名都转换为这些分配的整数之一。通过从 /etc/passwd 文件中查找用户名，可以查看 UNIX 中任何帐户的 UID 和主组 GID：

$grep bduda /etc/passwdbduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh      

 

第三个字段 (300) 是 UID，第四个字段 (350) 是您所属的主组的 GID。通过从 /etc/group 文件中搜索 GID 可以收集有关它的详细信息：

$grep ":350:" /etc/groupsecurity:!:350:bduda      

 

您可以看到，bduda 的主组为 security。由于 security 是 bduda 的主组，因此由 bduba 创建的文件都将属于这个组。

选择 UID 和 GID

对于 UID 和 GID 的编号范围有一些基本规则。AIX 系统管理员可以选择一个范围，从该范围开始分配 UID。100 以下的 UID 和 GID 一般是为系统帐户和服务保留的。在 AIX 中大约有 65,000 个可用 UID，因此不会出现不够用的问题。

---

为什么要更改 UID 或 GID？

有时，在从一个服务器到另一个服务器迁移服务器或应用程序时将需要更改 UID 或 GID。还有，在管理员操作失误时也需要更改 UID 或 GID。在使用 AIX High-Availability Cluster Multiprocessing (HACMP) 进行集群管理的环境中，所有集群服务器必须始终具有相同的 UID 和 GID；否则故障转移流程就无法正确工作。

---

在更改 UID 或 GID 时会发生什么情况？

需要理解的重要一点是，在更改 UID 或 GID 时将会影响到 AIX 中文件的权限级别。更改 UID 或 GID 会导致以前由该用户或组拥有的所有文件的所有权更改为该文件的以前所有者的实际整数。

---

更改 UID

可以通过两种方法更改 UID 和/或 GID。您可以使用 smitty，但本例中使用了命令行。下面是所用的语法：

Usage: usermod [ -u uid ] login      

 

现在我们更改用户 bin 的 UID：

$ grep ^bin /etc/passwdbin:!:2:2::/bin:$ usermod -u 5089 bin$ grep ^bin /etc/passwdbin:!:5089:2::/bin:      

 

通过运行 usermod 命令，可以将系统帐户 bin 的 UID 从 2 更改为 5089。请记住，bin 拥有的每个文件的所有权将为 2，原因是 AIX 不会自动将文件的所有权更改为用户的新 UID。

下面是在 UID 更改前用户的文件权限

-rw------- 1 bin  bin      29 2008-01-19 12:30 tester:        

 

UID 更改后的文件权限：

-rw------- 1 5089 bin      29 2008-01-19 12:30 tester      

 

用户 bin 不再拥有文件测试者的权限；您必须将文件更改回所有者 bin。这就是更改 UID 可能是管理员的艰巨任务的原因。

---

更改 GID

您已了解更改帐户的 UID 是多么容易——并了解到执行这项任务的最大问题之一。本部分将介绍使用命令行更改 GID 的语法。更改 GID 可能会更加复杂：

Usage: chgroup "attr=value" ... group      

 

更改组的 GID：

$grep bduda /etc/passwdbduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh$ grep security /etc/groupsecurity:!:350:bduda$ chgroup "id=7013" security3004-719 Warning: /usr/bin/chgroup does not update /etc/passwd with the new gid. $ grep security /etc/groupsecurity:!:7013:bduda      

 

您将收到一条警告消息，原因是即使更改了组的 GID，/etc/passwd 文件中的 GID 编号也不会更改。检查并确保：

$ grep bduda /etc/passwdbduda:!:300:350:Ben Duda:/home/bduda:/bin/ksh      

 

/etc/passwd 文件说明 bduda 有一个主组为 350。但是 security 有一个新 GID 为 7013。为解决此问题，您需要运行以下命令：

$ chuser "pgrp=security" bduda$ grep bduda /etc/passwdbduda:!:300:7013:Ben Duda:/home/bduda:/bin/ksh      

 

注意：在本例中，需要对每个将 security 作为其主组的用户使用 chuser 命令。请记住，当在 AIX 中更改 UID 和 GID 时，文件和目录上的权限并没有更改：必须手动更改文件。如果有许多文件，或者不知道所有文件都是哪些，则这种情况修复起来就非常困难。以下部分将介绍一些特定的示例，这些示例中显示了更改之前和更改之后的文件。

---

修复文件权限

当一个用户拥有一些文件并且您更改了该用户的 UID 和 GID 时，要查看发生了什么情况，请首先创建两个新文件 File1 和 File2。

UID

下面是这两个示例文件的属性：

$ls –l File* -rw-r-----   1 bduda    security         21 May 19 00:23 File1-rw-r-----   1 bduda    security         23 May 19 00:24 File2        

 

此文件的所有者是 bduda，属于 security 组。更改 bduda 的 UID：

$usermod -u 34578 bduda$grep bduda /etc/passwdbduda:*:34578:7:tester:/tmp/bduda:/usr/bin/ksh        

 

由于更改了 UID，现在我们查看文件的权限：

$ls -l File*-rw-r-----   1 203      security         21 May 19 00:23 File1-rw-r-----   1 203      security         23 May 19 00:24 File2          

 

您的两个文件的所有者现在的编号是 203，即 bduda 以前的 UID。必须将文件权限更改回帐户 bduda 才能修复这些权限：

$ chown bduda File*$ ls -l File*-rw-r-----   1 bduda    security         21 May 19 00:23 File1-rw-r-----   1 bduda    security         23 May 19 00:24 File2            

 

可以想像，在更改一个拥有 40,000 个文件的用户文件权限时的任务是多么艰巨！

GID

下面还有这两个示例文件的属性：

$ls –l File* -rw-r-----   1 bduda    security         21 May 19 00:23 File1-rw-r-----   1 bduda    security         23 May 19 00:24 File2              

 

组所有权是 security。更改 security 组的 GID：

$ chgroup "id=7013" security$grep security /etc/groupsecurity:!:7013:root,bduda                

 

由于更改了 GID，现在查看一下文件的权限：

$ls -l File*-rw-r-----   1 bduda    7                21 May 19 00:23 File1-rw-r-----   1 bduda    7                23 May 19 00:24 File2                  

 

您的两个文件现在的组权限为 7，即组 security 的 GID。必须将文件权限更改回安全组来修复这些权限：

$chgrp security File*$ls -l File*-rw-r-----   1 bduda    security         21 May 19 00:23 File1-rw-r-----   1 bduda    security         23 May 19 00:24 File2      

 

假定现在您没有修复文件上的权限。如果新用户或组是使用旧 UID 203 或旧 GID 7 创建的，则此新用户或组将成为系统上该用户以前拥有的每个文件的所有者和组。这对系统有不利影响；而且还造成了严重的安全问题。下一部分将讨论如何检查您的 AIX 系统，查看是否有任何无主文件。

---

准备进行更改：扫描您的系统查找无主文件

通过扫描系统来查找无主文件是一个好主意，而且可以在 AIX 上使用一些简单的命令执行此操作。要扫描无用户的文件，请从命令行运行以下命令：

find / /( -fstype jfs -o -fstype jfs2 /) -nouser -print      

 

根据您安装文件系统的方式，此命令可以检查整个系统中的无主文件并同时跳过安装的网络文件系统 (NFS)。您可以对组执行相同操作：

find / /( -fstype jfs -o -fstype jfs2 /) -nogroup -print           

 

查找无主文件和组只是完成了一半任务：还需要确定谁应该拥有它们及其应具有何种组权限。作为系统管理员，这不是一个非常简单的事情，较好的做法是查看目录所有者或组。然后，设置与目录匹配的权限。如果仍然不确定该怎么做，则更改根用户和根组的值也不失为一个好办法。

---

在环境中保持 UID 和 GID 的一致性

运行 UNIX 的大多数公司都有多个服务器。如果在多个服务器上执行相同的流程，则最佳实践是在整个企业中确保 UID 和 GID 是相同的。如果您使用的是某种类型的集中式用户管理，则使用 IBM HACMP 会容易得多，原因是 UID 和 GID 是同步的。

让我们假设您的应用程序使用的是 IBM DB2® Universal Database™。这是在两个 AIX HA 对上运行的任务关键型应用程序。这些服务器具有来回传递的文件系统，具体取决于哪个服务器为主服务器。运行 DB2 数据库的主服务器上的帐户的UID 为 300。

假设在标准生产周期中，您的主服务器崩溃，辅助服务器接管了主服务器的工作负荷。运行 DB2 数据库的辅助服务器上的帐户的 UID 为 400，这将是一个严重问题。主文件系统上的文件是使用 UID 为 300 的 DB2 帐户创建的。由于文件系统已经故障转移到辅助服务器，因此所有权是不正确的。DB2 文件不是由 UID 为 400 的 DB2 用户所拥有，而是由 UID 为 300 的用户拥有。数据库不拥有这些文件，因此根本无法正确工作。

有时，手动更改时需要太多的工作。这时可以使用脚本帮您执行此任务。

---

回页首

脚本

没有人愿意一次一个地更改 40,000 个文件所有者。较好的做法是编写一个脚本来查找所有文件——还可以使用脚本帮您修复权限。

搜索整个文件系统可能非常耗时。Perl 是一个很不错的工具，您可以使用该工具快速搜索整个文件系统。Perl 附带一个 find2perl 命令，该命令可以将常规的 AIX 查找命令转换为 Perl 代码。此代码搜索文件系统的速度要比常规的 UNIX 查找命令快：

$find2perl / /( -fstype jfs -o -fstype jfs2 /) -nouser -print > find_owner_script.pl$find2perl  / /( -fstype jfs -o -fstype jfs2 /) -nogroup -print > find_group_script.pl            

 

如果系统中没有 Perl，则可以使用常规的查找命令：

$find / /( -fstype jfs -o -fstype jfs2 /) -nouser -print > find_owner_script.txt$find  / /( -fstype jfs -o -fstype jfs2 /) -nogroup -print > find_group_script.txt      

 

现在您有一个使用 Perl 自动编写的脚本。此脚本可以快速找到所有无主文件并将其输出到屏幕上。如果愿意，还可以修改脚本将输出内容写入到一个文件。

现在，您需要确定应该是什么文件权限，然后更改它们，如以下部分所示。

所有者脚本

您可以在命令行上编写以下代码，或者将代码复制到脚本：

$ for file in $(cat output_from_find_owner_script.pl)    do        print "Old permissions: $(ls –l $file)" >> /tmp/UID_LOG        chown $new_owner $file        print "New permissions: $(ls –l $file) >> /tmp/UID_LOG            done      

 

下面是输出内容：

Old permissions: -rw------- 1 485  bin      29 2008-01-19 12:30 testerNew permissions: -rw------- 1 bin  bin      29 2008-01-19 12:30 testerOld permissions: -rw------- 1 987  bin      4098 2008-01-26 12:30 hostNew permissions: -rw------- 1 bin  bin      4089 2008-01-26 12:30 host        

 

组脚本

现在您可以对组执行类似的操作：

$for file in $(cat output_from_find_group_script.pl)    do        print "Old permissions: $(ls –l $file)" >> /tmp/GID_LOG        chgrp $new_group $file        print "New permissions: $(ls –l $file) >> /tmp/GID_LOG    done          

 

下面是输出内容：

Old permissions: -rw------- 1 765  bin      29 2008-01-19 12:30 passwdNew permissions: -rw------- 1 root  bin      29 2008-01-19 12:30 passwdOld permissions: -rw------- 1 983  bin      4098 2008-01-26 12:30 groupNew permissions: -rw------- 1 root  bin      4089 2008-01-26 12:30 group            

 

上述示例创建了一些日志文件，这些日志文件记录了更改之前和之后的文件权限。这些日志还可以验证您的脚本是否正常工作。

---

结束语

了解 UID 和 GID 在 UNIX 中的工作方式可能让您感到迷惑。如果您需要更改这些设置，则需要完全理解它们的工作原理，这样就不会对您的系统造成严重损害。通过使用一些脚本，您可以更快地解决 UID 和 GID 问题。