账号管理实例

账号管理不是随意建置几个账号就算了!有时候我们需要考虑到一部主机上面可能有多个账号在协同工作! 举例来说,我们学校的专题生是需要分组的,这些同一组的同学间必须要能够互相修改对方的数据文件, 但是同时这些同学又需要保留自己的私密数据,因此直接公开家目录是不适宜的。那该如何是好? 为此,我们底下提供几个例子来让大家思考看看:

任务一:单纯的完成上头交代的任务,假设我们需要的账号数据如下,你该如何实作?
这里写图片描述
先处理账号相关属性的数据:
[root@www ~]# groupadd mygroup1
[root@www ~]# useradd -G mygroup1 -c “1st user” myuser1
[root@www ~]# useradd -G mygroup1 -c “2nd user” myuser2
[root@www ~]# useradd -c “3rd user” -s /sbin/nologin myuser3

再处理账号的口令相关属性的数据:
[root@www ~]# echo “password” | passwd –stdin myuser1
[root@www ~]# echo “password” | passwd –stdin myuser2
[root@www ~]# echo “password” | passwd –stdin myuser3

要注意的地方主要有:myuser1 与 myuser2 都有支持次要群组,但该群组不见得会存在,因此需要先手动创建他! 然后 myuser3 是『不可登陆系统』的账号,因此需要使用 /sbin/nologin 这个 shell 来给予,这样该账号就无法登陆啰! 这样是否理解啊!接下来再来讨论比较难一些的环境!如果是专题环境该如何制作?

任务二:我的使用者 pro1, pro2, pro3 是同一个项目计划的开发人员,我想要让这三个用户在同一个目录底下工作, 但这三个用户还是拥有自己的家目录与基本的私有群组。假设我要让这个项目计划在 /srv/projecta 目录下开发, 可以如何进行?

  1. 假设这三个账号都尚未创建,可先创建一个名为 projecta 的群组,
    再让这三个用户加入其次要群组的支持即可:
    [root@www ~]# groupadd projecta
    [root@www ~]# useradd -G projecta -c “projecta user” pro1
    [root@www ~]# useradd -G projecta -c “projecta user” pro2
    [root@www ~]# useradd -G projecta -c “projecta user” pro3
    [root@www ~]# echo “password” | passwd –stdin pro1
    [root@www ~]# echo “password” | passwd –stdin pro2
    [root@www ~]# echo “password” | passwd –stdin pro3

  2. 开始创建此项目的开发目录:
    [root@www ~]# mkdir /srv/projecta
    [root@www ~]# chgrp projecta /srv/projecta
    [root@www ~]# chmod 2770 /srv/projecta
    [root@www ~]# ll -d /srv/projecta
    drwxrws— 2 root projecta 4096 Feb 27 11:29 /srv/projecta

例题:
将前一小节任务二中 /srv/projecta 这个目录,让 myuser1 可以进入查阅,但 myuser1 不具有修改的权力。
答:
由于 myuser1 是独立的使用者与群组,而 /srv 是附属于 / 之下的,因此 /srv 已经具有 acl 的功能。 透过如下的配置即可搞定:
1. 先测试看看,使用 myuser1 能否进入该目录?
[myuser1@www ~]$ cd /srv/projecta
-bash: cd: /srv/projecta: Permission denied <==确实不可进入!

  1. 开始用 root 的身份来配置一下该目录的权限吧!
    [root@www ~]# setfacl -m u:myuser1:rx /srv/projecta
    [root@www ~]# getfacl /srv/projecta
    file: srv/projecta
    owner: root
    group: projecta
    user::rwx
    user:myuser1:r-x <==还是要看看有没有配置成功喔!
    group::rwx
    mask::rwx
    other::—

  2. 还是得要使用 myuser1 去测试看看结果!
    [myuser1@www ~]cd/srv/projecta[myuser1@wwwprojecta] ll -a
    drwxrws—+ 2 root projecta 4096 Feb 27 11:29 . <==确实可以查询档名
    drwxr-xr-x 4 root root 4096 Feb 27 11:29 ..

[myuser1@www projecta]$ touch testing
touch: cannot touch `testing’: Permission denied <==确实不可以写入!
请注意,上述的 1, 3 步骤使用 myuser1 的身份,2步骤才是使用 root 去配置的!

上面的配置我们就完成了之前任务二的后续需求喔!这么简单呢!接下来让我们来测试一下,如果我用 root 或者是 pro1 的身份去 /srv/projecta 添加文件或目录时,该文件或目录是否能够具有 ACL 的配置? 意思就是说,ACL 的权限配置是否能够被次目录所『继承?』先试看看:

[root@www ~]# cd /srv/projecta
[root@www ~]# touch abc1
[root@www ~]# mkdir abc2
[root@www ~]# ll -d abc*
-rw-r–r– 1 root projecta 0 Feb 27 14:37 abc1
drwxr-sr-x 2 root projecta 4096 Feb 27 14:37 abc2
你可以明显的发现,权限后面都没有 + ,代表这个 acl 属性并没有继承喔!如果你想要让 acl 在目录底下的数据都有继承的功能,那就得如下这样做了!

# 4. 针对默认权限的配置方式:
配置规范:『 d:[ug]:使用者列表:[rwx] 』

让 myuser1 在 /srv/projecta 底下一直具有 rx 的默认权限!
[root@www ~]# setfacl -m d:u:myuser1:rx /srv/projecta
[root@www ~]# getfacl /srv/projecta
file: srv/projecta
owner: root
group: projecta
user::rwx
user:myuser1:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:myuser1:r-x
default:group::rwx
default:mask::rwx
default:other::—

[root@www ~]# cd /srv/projecta
[root@www projecta]# touch zzz1
[root@www projecta]# mkdir zzz2
[root@www projecta]# ll -d zzz*
-rw-rw—-+ 1 root projecta 0 Feb 27 14:57 zzz1
drwxrws—+ 2 root projecta 4096 Feb 27 14:57 zzz2
看吧!确实有继承喔!然后我们使用 getfacl 再次确认看看!

[root@www projecta]# getfacl zzz2
file: zzz2
owner: root
group: projecta
user::rwx
user:myuser1:r-x
group::rwx
mask::rwx
other::—
default:user::rwx
default:user:myuser1:r-x
default:group::rwx
default:mask::rwx
default:other::—
透过这个『针对目录来配置的默认 ACL 权限配置值』的项目,我们可以让这些属性继承到次目录底下

阅读更多
换一批

没有更多推荐了,返回首页