(U) 通过“exec"安装与“须藤".用户是“sudoer"使用 NOPASSWD [英] (U)Mounting through "exec" with "sudo". The user is a "sudoer" with NOPASSWD

查看:36
本文介绍了(U) 通过“exec"安装与“须藤".用户是“sudoer"使用 NOPASSWD的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经看过这两个:

但是,我的问题似乎有所不同.

<小时>

我构建了一个广泛的库,用于调用 Linux CLI 工具.它是围绕 proc_open 构建的,它是家族和 POSIX.

我正在使用它成功执行all(直到我遇到这个mount/umount 错误)CLI 工具.

现在,我正在构建一个 RAID 设置例程,包括 partprobeparted - rmmklabelmkpartmdadm - 停止零超级块创建ddmkfs 以及最终的 mount/umount.

实际上有两个优雅的例程,一个用于组装RAID,另一个用于拆卸.

正如标题所说,问题在于mountumount.上面列出的其他工具及其命令成功执行.

环境

Arch Linux - Linux stone 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux.

Arch 使用 systemd 运行 - 可能会以某种方式影响安装.

运行 mod_php(最新)的 Apache Web 服务器(最新).Apache 以 http:http 运行.

httpwheel 组中,wheels 是 sudoers - %wheel ALL=(ALL) NOPASSWD: ALL.
请不要开始 webserver 获得完整的 root 功能 讨论 - 该设备是 NAS,它运行自定义 WebOS,并且适用于内部网只要.即使有黑客尝试 - 这些很可能会破坏整个系统,这对客户来说是不健康的.NAS 是 Mobotix IP 摄像机 的存储设备,它运行大量依赖服务,并且单元是已经部署在 30 多个对象中,没有任何问题.简而言之,webserver 不是为网络服务,而是为操作系统服务.

在写之前,我补充说,为了快速测试,http 明确给 sudoers - http ALL=(ALL) NOPASSWD: ALL - 没有用.>

问题

RAID 组装过程中运行的最后一个命令是mount/dev/md/stone\:supershare/mnt/supershare,返回的退出代码为0.

执行后续安装导致:

mount:/dev/md127 已经挂载或/mnt/supershare busy/dev/md127 已经挂载在/mnt/supershare

退出代码为 32.因此,阵列安装在某处.

在上述 mount 之后执行 umount/dev/md/stone\:supershare,返回退出代码 0.执行后续的 umount 结果:

umount:/dev/md/stone:supershare: 未挂载

上面的命令是用 sudo 自动运行的.

因此,它已成功挂载并成功卸载,但是...我在 TTY0 上以 root 身份登录,在执行 mount 后运行 lsblk 操作,但是,我没有看到 mountpoint:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsda 8:0 0 55.9G 0 磁盘├─sda1 8:1 0 1M 0 部分├─sda2 8:2 0 1G 0 部分 [SWAP]├─sda3 8:3 0 12G 0 部分/└─sda4 8:4 0 16.6G 0 部分/家sdb 8:16 0 931.5G 0 磁盘└─sdb1 8:17 0 899M 0 部分└─md127 9:127 0 1.8G 0 raid0sdc 8:32 0 931.5G 0 磁盘└─sdc1 8:33 0 899M 0 部分└─md127 9:127 0 1.8G 0 raid0

尝试从 TTY0 执行相同的 mount 命令会成功安装它(lsblk 显示在后面).

<小时>

如果我使用 CLI 工具挂载它,然后使用 CLI 工具运行 mount -llsblk,挂载点是可见的.

立即以 root 身份从 TTY0 运行这两个命令,不显示挂载点.

<小时>

重新启动,重置所有挂载(不是自动挂载),然后从 TTY0 挂载并从 TTY0 运行 lsblk 显示挂载点.

然后,使用 CLI 工具运行 lsblk,显示挂载点.

然后,使用 CLI 工具运行 umount,退出代码 0 - 已卸载.

再次使用 CLI 工具运行 lsblk,不显示挂载点.

从 TTY0 运行 lsblk,仍然显示挂载点.

<小时>

看起来,当 mount/umount 与我的 CLI 工具一起运行时,它会为 sudo 会话运行程序私下执行命令.

umount 在 TTY0 挂载后,会卸载它,但再次 - 私下.

<小时>

从 TTY0 以 http 登录并在从 CLI 工具挂载 RAID 后运行 lsblk,不显示挂载点.这种否定为 sudo 会话运行程序私下执行".

<小时>

我还在 IBM 的:

<块引用>

mount 命令使用真实用户 ID,而不是有效用户 ID,来确定用户是否具有适当的访问权限.系统组成员可以发出设备挂载,前提是他们对挂载点和/etc/file systems 文件中指定的挂载具有写访问权限.具有 root 用户权限的用户可以发出任何挂载命令.

<小时>

我希望我已经解释得足够好并且不会太混乱,我也希望你们能在这里帮助我解决问题.

<小时>

更新 (2013-10-28)

我尝试在 Web 上下文之外使用 CLI 工具进行测试,这是一个简单的 PHP 文件,我使用 root 和自定义用户执行该文件.

在这两种情况下,挂载和卸载均成功.所以,它一定是 Apache 执行命令的原因,不过,我不明白为什么其他命令会起作用.

问题

导致问题的原因是什么,我该如何克服?

解决方案

总之,麻烦已经解决.

是 Apache 对应的 systemd 服务,具有 PrivateTmp=true 指令.显然,该指令使用新的文件系统命名空间执行进程.

<小时>

这个问题在尝试调试和修复问题时在互联网上引发了许多其他帖子.

  1. https://unix.stackexchange.com/questions/97897/sudo-mount-from-webserver-apache-by-mod-php-result-not-visible-by-root
  2. https://bbs.archlinux.org/viewtopic.php?id=172072
  3. https://unix.stackexchange.com/questions/98182/a-process-run-as-root-when-performing-mount-is-mounting-for-self-how-to-ma/98191#98191

每一个都来自我在这个过程中学到的东西.

我开始获取有关 mount 处理 EUID 的更深入信息.很快,我发现我的简单 sudo 调用实际上并没有使用 EUID 0 执行.这导致我对如何执行此操作进行了多次查询,作为回报,产生了类似 sudo -i 'su' -c 'mount/dev/sdb1/mnt/firstone' 和其他派生类的命令语法.

解决方案没有成功,我进一步看了.

我开始考虑尝试将条目添加到 /etc/fstab,这导致我遇到了大量权限问题.此外,sudo 和我的 CLI 工具被证明不适合该任务.让我们带上大武器 - 让我们用 -DBIG_SECURITY_HOLE 编译 Apache,也被称为,让 Apache 有可能以 root 运行.

让我们将条目附加到 tab,让我们尝试挂载...但...失败!

经过无数次测试、查询等等,我偶然发现了 per process mount 这导致我 这里 并向我打开了namespaces的维度.

好的,这说明了一切 - 检查 /proc//mounts 可以验证它,现在,让我们深入研究一下,看看如何克服它.

再次,在多次尝试但没有成功之后,我开始根据我对命名空间的新知识发布问题.缩小问题范围并变得更具技术性(至少我认为我做到了),最终导致用户 hiciu 指出我进入systemd 方向,特别是Apaches 服务 - PrivateTmp.

瞧!...显然 systemd 可以强制执行新的命名空间.

I've already taken a look at both of these:

But, my problem appears to be different.


I have built an extensive library that's used to call Linux CLI tools. It's built around proc_open, it's family and POSIX.

I'm using it to successfully execute all (until I hit this mount/umount bug) CLI tools.

Now, I'm building a RAID setup routine, that involves partprobe, parted - rm, mklabel, mkpart, mdadm - stop, zero-superblock, create, dd, mkfs and ultimately mount/umount.

There are actually two graceful routines, one for assembling the RAID, the other one for disassembly.

As the title says, the problem relies in mount and umount. The other tools and their commands listed above execute successfully.

Environment

Arch Linux - Linux stone 3.11.6-1-ARCH #1 SMP PREEMPT Fri Oct 18 23:22:36 CEST 2013 x86_64 GNU/Linux.

The Arch is running with systemd - might be that is somehow affecting the mounting.

An Apache web server (latest), that runs mod_php (latest). Apache is run as http:http.

http is in wheel group, and wheels are sudoers - %wheel ALL=(ALL) NOPASSWD: ALL.
Please, don't start the webserver being given a full root capabilities discussion - the unit is a NAS, it's running a custom WebOS, and it's meant for intranet only. Even if there are hacking attempts - those will, most probably, break the whole system and that's not healthy for the customer. The NAS is a storage for Mobotix IP cameras, it runs a load of dependent services and the units are already deployed in over 30 objects with no issues. In short, the webserver is not serving a web, but an OS.

Before writing, I added, for a quick test, http explicitly to sudoers - http ALL=(ALL) NOPASSWD: ALL - didn't work.

Problem

The last command run in the RAID assembly process is mount /dev/md/stone\:supershare /mnt/supershare, which returns with an exit code of 0.

Performing a subsequent mount results in:

mount: /dev/md127 is already mounted or /mnt/supershare busy
/dev/md127 is already mounted on /mnt/supershare

with an exit code of 32. So, the array is mounted somewhere.

Performing an umount /dev/md/stone\:supershare afterwards the above mount, returns with an exit code of 0. Performing an subsequent umount results in:

umount: /dev/md/stone:supershare: not mounted

The commands above are auto-run with sudo.

So, it's mounted successfully and unmounted sucessfully, but... I'm logged in as root on TTY0, running lsblk after having performed the mount operation, yet, I do not see the mountpoint:

NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0  55.9G  0 disk
├─sda1      8:1    0     1M  0 part
├─sda2      8:2    0     1G  0 part  [SWAP]
├─sda3      8:3    0    12G  0 part  /
└─sda4      8:4    0  16.6G  0 part  /home
sdb         8:16   0 931.5G  0 disk
└─sdb1      8:17   0   899M  0 part
  └─md127   9:127  0   1.8G  0 raid0
sdc         8:32   0 931.5G  0 disk
└─sdc1      8:33   0   899M  0 part
  └─md127   9:127  0   1.8G  0 raid0

Attempting the same mount command from TTY0 mounts it successfully (lsblk displays after).


If I mount it with my CLI tool, then run mount -l and lsblk also with the CLI tool, the mountpoint is visible.

Running immediately both commands from TTY0 as root, do not display the mountpoint.


Rebooting, to reset all mounts (not automounted), then, mounting from TTY0 and running lsblk from TTY0 displays the mountpoint.

Then, running lsblk with CLI tool, displays the mountpoint.

Then, running umount with CLI tool, exit code 0 - unmounted.

Running lsblk with CLI tool again, does not display the mountpoint.

Running lsblk from TTY0, still does display the mountpoint.


It appears that when the mount/umount is run with my CLI tool, it executes the commands privately for the sudo session runner.

umounting after TTY0 has mounted, does unmount it, but again - privately.


Logging in from TTY0 as http and running lsblk after having mounted the RAID from CLI tool, the mountpoint is not displayed. This kind of negates the "executes privately for the sudo session runner".


I've also found a material in IBM's:

The mount command uses the real user ID, not the effective user ID, to determine if the user has appropriate access. System group members can issue device mounts, provided they have write access to the mount point and those mounts specified in the /etc/file systems file. Users with root user authority can issue any mount command.


I hope I've explained good enough and not too confusing, I also hope that you guys will be able to help me catch the issue here.


Update (2013-10-28)

I attempted a test with the CLI tool outside web context, a simple PHP file, that'd I exec with root and a custom user.

In both scenarios, the mounting and unmounting was successful. So, it must be something with Apache executing the commands, though, I don't understand why do other commands work.

Question

What is causing the issue, and how do I overcome it?

解决方案

In short, the hassle has been resolved.

It was the Apache's corresponding systemd service, that had PrivateTmp=true directive. Apparently, the directive executes the process with a new file system namespace.


This question, while attempting to debug and fix the issue spawned a numerous other posts around the internet.

  1. https://unix.stackexchange.com/questions/97897/sudo-mount-from-webserver-apache-by-mod-php-result-not-visible-by-root
  2. https://bbs.archlinux.org/viewtopic.php?id=172072
  3. https://unix.stackexchange.com/questions/98182/a-process-run-as-root-when-performing-mount-is-mounting-for-self-how-to-ma/98191#98191

Each derived from stuff I've learn in the process.

I started with getting deeper information about mount working on EUID. Soon, I found out that my simple sudo call is actually not executing with EUID 0. That led me to multiple queries on how to do so, that in return spawned command syntax like sudo -i 'su' -c 'mount /dev/sdb1 /mnt/firstone' and other derivatives.

Having no success with the solution, I looked further.

I started to think of trying to add the entry to /etc/fstab, that led me to loads of permission issues. Also, sudo and my CLI tool proved to be incomplete for the task. Lets bring the big weapons - lets compile Apache with -DBIG_SECURITY_HOLE, also known as, give Apache the possibility to be run as root.

Lets append entry to the tab, lets attempt to mount... and... fail!

After numerous tests, queries and what not, I stumbled upon per process mount that led me here and opened the dimension of namespaces to me.

Okay, that explains everything - checking /proc/<pid>/mounts validates it, now, lets gnaw deeper and see how to overcome it.

Again, after numerous attempts and no success, I started posting questions based around my fresh knowledge of namespaces. Narrowing the questions down and becoming more technical (at least I think I did), that eventually led to a user hiciu who pointed me into systemd direction, specifically, Apaches service - PrivateTmp.

Voila! ...apparently systemd can enforce new namespaces.

这篇关于(U) 通过“exec"安装与“须藤".用户是“sudoer"使用 NOPASSWD的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆