sodu 命令场景分析

摘自:http://www.cnblogs.com/hazir/p/sudo_command.html

sudo 命令情景分析

Linux 下使用 sudo 命令,可以让普通用户也能执行一些或者全部的 root 命令。本文就对我们常用到 sudo 操作情景进行简单分析,通过一些例子来了解 sudo 命令相关的技巧。

情景一:用户无权限执行 root 命令

普通用户登录 shell 之后,如果自身没有权限访问某个文件或执行某个命令时,若该用户获得root授权,那么就可以在需要执行的命令之前加上 sudo,临时切换到root用户的权限,完成相关的操作。在sudo于1980年前后被写出之前,一般用户管理系统的方式是利用su切换为超级用户。但是使用su的缺点之一在于必须要先告知超级用户的密码,而sudo使一般用户不需要知道超级用户的密码即可获得权限。

那么哪些用户可以临时获得 root 权限呢?这就需要在 /etc/sudoers 文件中进行配置:

授权给单个用户:

# User privilege specification
guohl   ALL=(ALL) ALL

上面这个例子中:

  • guohl:允许使用 sudo 的用户名
  • ALL:允许从任何终端(任何机器)使用 sudo
  • (ALL):允许以任何用户执行 sudo 命令
  • ALL:允许 sudo 权限执行任何命令

如果我们想让用户 test 只能在本主机(主机名为guohl-pc)以 root 账户执行/bin/chown、/bin/chmod 两条命令,那么就应该这样配置:

# User privilege specification
test   guohl-pc=(root) /bin/chown,/bin/chmod

如果test 登录之后运行 sudo 命令,不满足上面三个条件命令均失败。

授权给用户组:

# Allow members of group sudo to execute any command
# (Note that later entries override this, so you might need to move it further down)
%sudo ALL=(ALL) ALL

和授权给单个用户类似,只不过将用户名在这里换成%组名,所有在该组中的用户都按照此规则进行授权。对于该例,所有在 sudo 组内的用户都有在任何终端(第一个ALL)、以任何用户(第二个ALL)、执行任何命令(第三个ALL)的权限,查看 /etc/group 文件可以知道哪些用户属于 sudo 组。

举例:

如果当前帐号在 /etc/sudoers 文件中被授予 sudo 的权限,那么你就可以将任何 root 命令作为 sudo 命令的参数,使用 root 权限来执行该命令。举例来说,挂载一个文件系统只能由 root 来执行,但是一个普通用户也可以使用 sudo 来挂载:

$sudo mount /dev/sda7 /mnt
[sudo] password for guohailin:

首次使用会要求你输入当前用户的密码,系统确实输入正确即以 root 权限来执行 mount 命令,接下来一段时间(默认为5分钟)再次使用 sudo 命令就不需要输密码了。

情景二:vim 编辑后发现忘记使用 sudo

我们经常会遇到这样的一个囧境:使用 vim 对某个文件进行编辑,编辑完之后,按 ESC 之后回到普通模式,再按 :wq 准备保存退出时,发现没有权限对该文件进行修改,我们在使用 vim 命令时忘记在前面加 sudo 了。我就经常出现这种问题,之前的做法是只能不保存强退,再加上 sudo 重新编辑。

但是今后我们再也不需要用这么愚蠢的做法了,我们可以在 vim 的普通模式下,按 :w !sudo tee % ,这样就可以 root 权限来保存文件了,你也无需因为自己一时忘记加个 sudo 而沮丧懊恼了!

情景三:执行 root 命令忘记加 sudo

我们还会遇到这样稍微好一点的情形:输入一个长长的命令,按 Enter 之后出现无权限操作,因为我们忘记加 sudo 了。大多人的做法是按  回到上一条命令,在该命令之前加上 sudo,再执行该命令。

以后,我们无需这样了,只要输入 sudo !! 即可,这里的 !! 代表上一条命令。如:

$ head -n 4 /etc/sudoers
head: cannot open `/etc/sudoers‘ for reading: Permission denied

$ sudo !!
sudo head -n 4 /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the ‘visudo‘ command as root.
#

情景四:shell 内置命令如何使用 sudo

shell 是一个交互式的应用程序,在执行外部命令时通过 fork 来创建一个子进程,再通过 exec 来加载外部命令的程序来执行,但是如果一个命令是 shell 内置命令,那么只能直接由 shell 来运行。sudo 的意思是,以别的用户(如root)的权限来 fork 一个进程,加载程序并运行,因此 sudo 后面不能跟 shell 的内置命令,如:

$ sudo cd /sys/kernel/debugfs
sudo: cd: command not found

在这种情况,我们又没有 root 账户的密码,我们怎样执行该命令呢?有种办法就是使用 sudo 获得root shell 的权限,然后在root shell 中执行该命令。进入root shell 很简单,输入sudo bash 确认本用户的密码即可,此时你会发现命令提示符显示当前是 root。一旦获得root shell,你可以执行任何命令而不需要在每条命令前输入sudo了。

另外,常用的shell 内置命令在这里 有简单介绍,我们可以使用 type 命令来查看命令的类型,如:

$ type ls
ls is /bin/ls
$ type umask
umask is a shell builtin

情景五:sudo 操作记录日志

作为一个 Linux 系统的管理员,不仅可以让指定的用户或用户组作为root用户或其它用户来运行某些命令,还能将指定的用户所输入的命令和参数作详细的记录。而sudo的日志功能就可以用户跟踪用户输入的命令,这不仅能增进系统的安全性,还能用来进行故障检修。但是要记录sudo的日志还要一些简单的配置:

  • 创建sudo日志文件
    我们将sudo日志文件放置在 /var/log/sudo.log 文件中:

      $ sudo touch /var/log/sudo.log
  • 修改 /etc/rsyslog.conf 配置文件
    我使用系统为Ubuntu13.04 为改名字,但有些系统名为/etc/syslog.conf,注意不同发行版之间的差别,在该文件加入下面一行:
      local2.debug    /var/log/sudo.log    #空白不能用空格,必须用tab
  • 修改 /etc/sudoers 配置文件
    注意网上很多关于sudo日志文件配置都缺少这一步!在该文件中加入下面一行:
      Defaults    logfile=/var/log/sudo.log
  • 重启 syslog 服务:
      $ sudo service rsyslog restart
  • 查看 sudo 日志记录:
    经过上面的配置,sudo 的所有成功和不成功的sudo
    命令都记录到文件/var/log/sudo.log 中,例如我运行几条sudo 命令之后,查看该文件的记录如下:
      $ cat sudo.log
      Sep 20 22:10:51 : guohailin : TTY=pts/1 ; PWD=/var/log ; USER=root ;
          COMMAND=/bin/cat /etc/sudoers
      Sep 20 22:11:36 : guohailin : TTY=pts/1 ; PWD=/var/log ; USER=root ;
          COMMAND=/usr/sbin/service rsyslog restart
      Sep 20 22:11:45 : guohailin : TTY=pts/1 ; PWD=/var/log ; USER=root ;
          COMMAND=/bin/ls
      Sep 20 22:12:08 : guohailin : TTY=pts/1 ; PWD=/var/log ; USER=root ;
          COMMAND=/bin/ls /root/

参考资料:

时间: 2024-10-30 10:08:00

sodu 命令场景分析的相关文章

scala akka 修炼之路6(scala函数式柯里化风格应用场景分析)

胜败兵家事不期,包羞忍耻是男儿--斗牛士fighting,fighting,fighting... 小象学习和使用scala也一段时间了,最初小象学习scala主要为了学习spark生态,但是深入学习scala的一些特性后,深深被scala函数式和面向对象的风格所折服,不得不赞美设计这门语言的设计者.小象大学阶段在使用MATLAB做数据分析和自动化设计时,就非常喜欢使用MATLAB的命令行和面向矩阵运算的风格编写分析代码:喜欢使用java编写层次化和清晰的模块接口,而这些Scala语言设计中都有

mariadb 10 多源复制(Multi-source replication) 业务使用场景分析,及使用方法

mariadb 10 多源复制(Multi-source replication) 业务使用场景分析,及使用方法 官方mysql一个slave只能对应一个master,mariadb 10开始支持多源复制,一个slave可以有多个master,分别从各自的master复制不同的DB. 这个特性可以用在OLAP环境中,传统电商DB都是拆了再拆,分库分表,sharding,而OLAP环境或者大数据平台环境,通常需要各种数据的聚合,多个平台多个DB数据的复合查询,而这些数据分散在各个库中,怎么办了,当

flume实际生产场景分析

需求:A B两台日志服务器实时生产日志主要类型为access.log.nginx.log.web.log,现在要求:把A.B机器中的access.log.nginx.log.web.log 采集汇总到 C 机器上然后统一收集到 hdfs中,但是在hdfs中要求的目录为:   /source/logs/access/日期/**   /source/logs/nginx/日期/**   /source/logs/web/日期/**场景分析: 规划:hadoop01(web01):    source

云计算学习路线图素材课件:Docker容器应用场景分析

Docker容器是一个开源的应用容器引擎,它能够自动执行重复性任务,例如搭建和配置开发环境,用户可以方便地创建和使用容器,还可以进行版本管理.复制.分享.修改.有很多初学云计算的同学不清楚Docker容器的使用方法以及应用场景,接下来就给大家简单分享一下云计算学习路线图素材课件:Docker容器应用场景分析. Docker是一个使用 Go 语言开发的,并且开源的应用容器引擎,基于LXC(Linux Container)内核虚拟化技术实现,提供一系列更强的功能,比如镜像.Dockerfile等:

基于linux与busybox的reboot命令流程分析

http://www.xuebuyuan.com/736763.html 基于Linux与Busybox的Reboot命令流程分析 *************************************************************************************************************************** 作者:EasyWave                                                

典型用户及用户场景分析

典型用户及用户场景分析 糖糖---一个热爱编程的准程序员 名字 糖糖 性别.年龄 男,刚21岁 收入 暂时还没有 比例和重要性 市场比例很大,很重要 典型场景 写了一段自认为很优秀的代码,想要保存在一个合适的地方 使用本软件/服务的环境 需要保存自己的代码 生活/工作情况 现在还是学生,努力学习 知识层次和能力 大学还未毕业,学习热情极高,编程能力较好 用户的动机.目的和困难 保存代码,但是没有合适的地方 用户的偏好 喜欢给代码增加自定义的标签 呆呆---热爱思考人生的缺乏编程联系的“小学生”

用户分析和场景分析

用户分析: 名字:二柱子 年龄:30 收入:3000元一个月 代表的比例:代表的是程序维护人员 二柱子:二柱子是一名负责任的找到了网站的管理员,对电脑有很好的掌握,平常最反感得是那些在网站中发小广告的,严重影响了网站的秩序,对网站维护产生干扰, 用户偏好: 场景分析:在进行维护网站的时候,发现有人在网站中发小广告,这让他很生气,希望把这个用户移除出这个网站,并对这个ip进行判断,禁止这个ip访问该网站.

第1阶段——uboot查找命令run_command函数和命令定义分析(6)

本节主要学习,run_command函数命令查找过程,命令生成过程 1.run_command函数命令查找过程分析:在u-boot界面中(main_loop();位于u-boot-1.1.6/common/main.c ):a 输入命令字符串b 将命令字符串代入函数run_command()c run_command():判断命令字符串,在argv[0]里保存命令名,并调用find_cmd(argv[0]))函数查找内存中该命令结构体,判断各个参数,执行命令等d find_cmd(argv[0]

电商抢购秒杀系统的设计_1_应用场景分析

电商抢购秒杀系统的设计_1_应用场景分析 概述 所谓知已知彼,百战不殆,在开始详细介绍实战中的抢购秒杀系统时,我们了解一些抢购秒杀系统系统面临的尴尬与难点.另外需要说明一点,下面的内容都是在工作中慢慢总结得来,我们团队也是慢慢摸着石头过河,甚至最初的的架构设计并非是抢购秒杀系统. 评估系统处理能力 理论基础:LNMP的并发考虑与资源分配 虽然有基础去评估我们应用系统的处理能力,但是电商购买的业务流程挺复杂,从登录,商品详情,购物车,填写收货地址,选择支付方式,创建订单,完成支付,以及隐含的定时服