当前位置:  建站>运营/SEO

[1]用户管理命令useradd等的深入理解及手动创建用户

一 搞清楚adduser和useradd的关系

[root@larrywen opt]# type adduser
adduser is /usr/sbin/adduser
[root@larrywen opt]# type useradd
useradd is /usr/sbin/useradd
[root@larrywen opt]# which useradd
/usr/sbin/useradd
[root@larrywen opt]# which adduser
/usr/sbin/adduser
[root@larrywen opt]# ls -l /usr/sbin/adduser /usr/sbin/useradd
lrwxrwxrwx. 1 root root     7 Jul 21 14:11 /usr/sbin/adduser -> useradd
-rwxr-x---. 1 root root 97040 Feb 24  2011 /usr/sbin/useradd

二 可以使用useradd命令添加用户

[root@larrywen /]# useradd zhink
[root@larrywen /]# id zhink
uid=501(zhink) gid=502(zhink) groups=502(zhink)

三 使用useradd和adduser创建用户执行流程（修改文件）

#用户相关信息
[root@serv01 test]# ls /etc/passwd
/etc/passwd
#用户密码信息
[root@serv01 test]# ls /etc/shadow
/etc/shadow
#组的信息
[root@serv01 test]# ls /etc/group
/etc/group
#组密码相关信息
[root@serv01 test]# ls /etc/gshadow
/etc/gshadow
#用户的家目录
[root@serv01 test]# ls /home
zhink
#邮件相关的信息
[root@serv01 test]# ls /var/mail
zhink

四 手工创建用户

        1.修改用户信息文件，比如我改成这样，每个字段的含义可以使用man 5 passwd查看配置文件

[root@serv01 home]# vim /etc/passwd
[root@serv01 home]# tail -1 /etc/passwd
hongyi:x:501:501::/home/hongyi:/bin/bash

        2.修改用户的密码文件，可以使用grub-md5-crypt工具生成一个密码，比如我改成这样,每个字段的含义可以使用man 5 shadow查看配置文件

[root@serv01 test]# vim /etc/shadow
[root@serv01 home]# tail -1 /etc/shadow
hongyi:$1$ApQEH1$tu32jdS4O/c43Xzppyfmi1:15910:0:99999:7:::
[root@serv01 test]# grub-md5-crypt 
Password: 
Retype password: 
$1$ApQEH1$tu32jdS4O/c43Xzppyfmi1

        3.修改组文件，比如我改成这样,每个字段的含义可以使用man5 group查看配置文件

[root@serv01 test]# vim /etc/group
hongyi:x:501

        4.修改组密码文件，比如我改成这样,每个字段的含义可以使用man5 gshadow查看配置文件

[root@serv01 test]# vim /etc/gshadow
hongyi:!::

        5.创建用户主目录

[root@serv01 home]# mkdir /home/hongyi

        6.拷贝模板文件

        我们查看其他用户的主目录，可以看到有一些隐藏的配置文件，我们必须拷贝到用户的主目录

[root@serv01 home]# ll zhink/ -a
total 24
drwx------. 3 zhink hink 4096 Jul 24 22:18.
drwxr-xr-x. 5 root  root 4096 Jul 24 23:09 ..
-rw-r--r--. 1 zhink hink   18 Jan 27 2011 .bash_logout
-rw-r--r--. 1 zhink hink  176 Jan 27 2011 .bash_profile
-rw-r--r--. 1 zhink hink  124 Jan 27 2011 .bashrc
drwxr-xr-x. 2 zhink hink 4096 Jul 16  2010 .gnome2

        这些配置文件在/etc/skel目录下，我们拷贝到用户主目录就可以了

cp /etc/skel/. /home/hongyi/ -raf

        7.修改用户主目录的所有者 组拥有者 权限

chown hongyi.hongyi /home/hongyi/ -R
chmod 700 /home/hongyi/

        8.创建用户的邮件文件

touch /var/mail/hongyi

        9.修改该文件的所有者 组拥有者 权限

[root@serv01 home]# chown hongyi.mail/var/mail/hongyi
[root@serv01 home]# chmod 660/var/mail/hongyi

        10.我们使用ssh登录，测试手工创建用户是否成功

[root@larrywen Desktop]# ssh hongyi@192.168.1.11
hongyi@192.168.1.11's password:
Last login: Wed Jul 24 23:14:22 2013 from192.168.1.1
[hongyi@serv01 ~]$
[hongyi@serv01 ~]$ ls -a
. ..  .bash_history  .bash_logout .bash_profile  .bashrc  .gnome2

五 写在最后

        当然本文只是对理解useradd命令所做的实验，生产环境中肯定不会这样操作。其实学习的过程中使用这种方式可以让你理解命令的背后到底做了什么。

  我的邮箱：wgbno27@163.com
  新浪微博：@Wentasy27         
  微信公众平台：JustOracle（微信号：justoracle）
  数据库技术交流群：336882565（加群时验证 From CSDN XXX）
  Oracle交流讨论组：https://groups.google.com/d/forum/justoracle
  By Larry Wen

  @Wentasy 博文仅供参考，欢迎大家来访。如有错误之处，希望批评指正。原创博文如需转载请注明出处，谢谢 :) [CSDN博客]

[2]passwd文件没有任何权限，为什么普通用户可以正常登录

我们可以看到密码文件没有任何权限，用户登录时要需要读取密码文件，如果正确是怎样通过验证的呢？

[root@serv01 learning]# ls /etc/shadow -l
----------. 1 root root 1155 Sep 20 22:11/etc/shadow

因为该文件具有s属性。s：s针对命令，对与普通文件或者目录没有任何意义，特权位，命令执行的一瞬间具有root权限

[root@serv01 learning]# ls /etc/shadow -l
----------. 1 root root 1155 Sep 20 22:11/etc/shadow
[root@serv01 learning]# which passwd
/usr/bin/passwd
[root@serv01 learning]# ls -l/usr/bin/passwd
-rwsr-xr-x. 1 root root 25336 Jan 29  2010 /usr/bin/passwd

演示修改vim的权限，可以打开任何文件在任何地方修改文件

[root@serv01 learning]# which vim
/usr/bin/vim
[root@serv01 learning]# ls -l /usr/bin/vim
-rwxr-xr-x. 1 root root 1933032 Feb 15  2011 /usr/bin/vim
[root@serv01 learning]# chmod u+s/usr/bin/vim
[root@serv01 learning]# ls -l /usr/bin/vim
-rwsr-xr-x. 1 root root 1933032 Feb 15  2011 /usr/bin/vim

 

第一步 在当前目录创建文件

[zhink@serv01 bbbb]$ vim file

第二步 查看文件的信息

[zhink@serv01 bbbb]$ ls -l file
-rw-rw-r--. 1 root zhink 6 Sep 20 23:17file

第三步 在root的根目录下创建文件，可以看到文件所有者时root

[zhink@serv01 bbbb]$ vim /root/test.txt

第四步 查看test.txt的权限，可以看到文件所有者是root

[root@serv01 learning]# ls /root/test.txt-l
-rw-rw-r--. 1 root zhink 12 Sep 20 23:17/root/test.txt
[root@serv01 learning]# cat bbbb/file
hello
[root@serv01 learning]# cat /root/test.txt
hello,world

第五步 此时编辑shadow文件也可以

[zhink@serv01 bbbb]$ vim /etc/shadow
#为了系统的安全性，还原vim命令的权限
[root@serv01 learning]# chmod u-s /usr/bin/vim
[root@serv01 learning]# ls /usr/bin/vim -l
-rwxr-xr-x. 1 root root 1933032 Feb 15  2011 /usr/bin/vim

第六步 还原vim的属性，再次查看密码文件，发现看不到内容

[zhink@serv01 bbbb]$ vim /etc/shadow

第七步 g+s后的实验

#目录继承s，文件继承w
[root@serv01 learning]# chmod g+s cccc/
[root@serv01 learning]# cd cccc/
[root@serv01 cccc]# chmod g+w ../cccc/
[root@serv01 cccc]# mkdir oooo
 
[zhink@serv01 cccc]$ ll
total 8
drwxrwsr-x. 2 zhink root 4096 Sep 20 23:29ffff
-rw-rw-r--. 1 zhink root    0 Sep 20 23:30 file
drwxr-sr-x. 2 root  root 4096 Sep 20 23:26 oooo

  我的邮箱：wgbno27@163.com
  新浪微博：@Wentasy27         
  微信公众平台：JustOracle（微信号：justoracle）
  数据库技术交流群：336882565（加群时验证 From CSDN XXX）
  Oracle交流讨论组：https://groups.google.com/d/forum/justoracle
  By Larry Wen

  @Wentasy 博文仅供参考，欢迎大家来访。如有错误之处，希望批评指正。原创博文如需转载请注明出处，谢谢 :) [CSDN博客]

[3]一次slab异常排查过程

内核版本3.0.74
arm， 2核

在执行lmbench内存压力测试时，发生了好几次slab异常，每次异常都是在这个地方：

kernel BUG at mm/slab.c:3067!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
[<c003c6ec>] (__dabt_svc+0x4c/0x60) from [<c00405a4>] (__bug+0x1c/0x28)
[<c00405a4>] (__bug+0x1c/0x28) from [<c00c9d0c>] (cache_alloc_refill+0x3a0/0x654)
[<c00c9d0c>] (cache_alloc_refill+0x3a0/0x654) from [<c00ca174>] (kmem_cache_alloc+0xb0/0xc4)
[<c00ca174>] (kmem_cache_alloc+0xb0/0xc4) from [<c0057b04>] [color=Red](copy_process+0x9c/0xdbc)[/color]
[<c0057b04>] (copy_process+0x9c/0xdbc) from [<c0058890>] (do_fork+0x48/0x288)
[<c0058890>] (do_fork+0x48/0x288) from [<c003cc40>] (ret_fast_syscall+0x0/0x30)

对应的语句是cache_alloc_refill函数：

/*
 * The slab was either on partial or free list so
 * there must be at least one object available for
 * allocation.
 */
 BUG_ON(slabp->inuse >= cachep->num);

根据函数的逻辑，代码走到这里的时候，说明刚从cache的partial或者free链表里取得了一个可用slab，
而这个获取的slab，一定是还有可用的obj，即slabp->inuse一定小于上限cachep->num。

为确认在BUG_ON前，打印slabp->inuse和cachep->num的值，出错时：

slabp->inuse:5,cachep->num:5

在正常情况下，打印task_struct_cache的num上限确实是5。

代码走到了这里，并触发了BUG_ON，起先怀疑：
1）这个版本的内核(3.0.74)是否有slab方面的bug？ 
2）是否这个arm架构的spinlock的实现有问题？

但后来一想，内核不可能做的这么糟糕，被lmbench内存压力小测一下就出异常，应该是其他什么地方出问题了。

为了进一步分析，先把该slab的内容都打印一下，看有没有什么线索：

partial.next:df913000,free.next:df802df0
slabs_partial pointer:df802de0,slabs_free pointer:df802df0
slab get from partial
cache 'task_struct'(5), slabp df913000(inuse:5,free:-257),kmem_map vaddr:0xdf91301c
Hexdump:
000: 00 50 90 df e0 2d 80 df 40 00 00 00 40 30 91 df
010: 05 00 00 00 ff fe ff ff 00 00 ad de 03 00 00 00
020: ff ff ff ff 00 00 00 00 ff fe ff ff ff ff ff ff

上面有两个重要信息，首先是从task_struct_cache的 partial链表里取出了一个slab，然后该slab的free字段是非法的-257(0xfffffeff)
Hexdump的 前面0x1c字节是slab描述符，后面的是slab的obj位图数据：

struct slab {
        union {
                struct {
                        struct list_head list;  0xdf905000,0xdf802de0
                        unsigned long colouroff; 0x40
                        void *s_mem;                /* including colour offset */ 0xdf913040
                        unsigned int inuse;        /* num of objs active in slab */ 0x5
                        kmem_bufctl_t free; 0xfffffeff:typedef unsigned int kmem_bufctl_t; 
                        unsigned short nodeid;
                };
                struct slab_rcu __slab_cover_slab_rcu;
        };
};

问题就是，这个 0xfffffeff 是怎么出来的？slab描述符周围的值看上去都是正常的。
很有可能是内存bit跳变。本来该slab已经满了，但由于slabp的free从fffffff变成fffffeff，

因此不加入full list，而加入了partial_list。下一次再分配slab的时候，

就从partial里取了一个非法的slab，导致分配时cache_alloc_refill里的BUG_ON被触发。

/* move slabp to correct slabp list: */
list_del(&slabp->list);
if (slabp->free == BUFCTL_END)
    list_add(&slabp->list, &l3->slabs_full);
else
    list_add(&slabp->list, &l3->slabs_partial);

后续了解到，这个DDR是超频到533M使用的，于是将其恢复到正常频率400M，测试lmbench再没有发生异常。