当前位置： 文江博客话题详情

Clearcase：如何控制SUID程序是否在视图中运行？

发布于 2024-10-19 10:40:10 字数 6014 浏览 2 评论 0原文

我们有两台机器（正在讨论中）运行 ClearCase - ClearCase 的不同版本。否则，它们的设置大致相同 - 相同的 Linux x86/64 内核等。

在一台计算机上，视图中的 SUID 根程序与 SUID 根程序一样工作。

在另一台机器上，视图中的 SUID root 程序无法使用 SUID 权限，从而导致意外结果。

到目前为止，我们发现的唯一区别是：

  • 工作视图：CC 7.0.1
  • 非工作视图：CC 7.1.1.1

如果重要的话，我可以提供 cleartool -version 的完整输出，但我怀疑不会。这些是列出的第一个版本。

问题

  1. 这是 ClearCase 版本之间的已知差异，还是一个配置项，还是其他什么？
  2. 是否可以配置较新版本的 ClearCase (MVFS) 以允许 SUID 根程序“正常”运行？
  3. 如果是可配置的，我们如何更改配置使新版本允许SUID程序？

我们有无数台机器在许多不同的平台上运行 ClearCase。有传言称，在某些机器上，我们的 SUID 软件必须在“视图之外”运行才能工作。现在有人报告了一个错误 - 并且花了大半天的时间来缩小差异。问题中提到的问题似乎是一个合理的解释。如果是别的事，那就这样吧。我仍然需要把今天失去的头发重新找回来！

额外信息

所有视图都是动态的，而不是快照。

这是 SUID 程序运行的机器上的 cleartool lsview -l -full -pro -cview 的输出，运行 ClearCase 7.0.1：

Tag: idsdb00222108.jleffler.toru
  Global path: /net/toru/work4/atria/idsdb00222108.jleffler.toru.vws
  Server host: toru
  Region: lenexa
  Active: YES
  View tag uuid:6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View on host: toru
View server access path: /work4/atria/idsdb00222108.jleffler.toru.vws
View uuid: 6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View owner: lenexa.pd/jleffler

Created 2011-01-31T11:58:11-08:00 by jleffler.rd@toru
Last modified 2011-02-26T22:32:49-08:00 by [email protected]
Last accessed 2011-02-26T22:44:55-08:00 by [email protected]
Last read of private data 2011-02-26T22:44:55-08:00 by [email protected]
Last config spec update 2011-02-26T01:10:36-08:00 by [email protected]
Last view private object update 2011-02-26T22:32:49-08:00 by [email protected]
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/jleffler : rwx (all)
Group: lenexa.pd/rd     : rwx (all)
Other:                  : rwx (all)
Additional groups: lenexa.pd/RAND lenexa.pd/ccusers lenexa.pd/ccids lenexa.pd/ccos

这是 SUID 程序不运行的机器上的输出 ' work'，运行 ClearCase 7.1.1.1：

Tag: new.jleffler.zeetes
  Global path: /tmp/jl/new.jleffler.zeetes.vws
  Server host: zeetes
  Region: lenexa
  Active: YES
  View tag uuid:f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View on host: zeetes
View server access path: /tmp/jl/new.jleffler.zeetes.vws
View uuid: f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View owner: lenexa.pd/informix

Created 2011-02-25T18:40:11-06:00 by informix.informix@zeetes
Last modified 2011-02-25T18:49:56-06:00 by informix.informix@zeetes
Last accessed 2011-02-25T18:50:31-06:00 by informix.informix@zeetes
Last read of private data 2011-02-25T18:50:31-06:00 by informix.informix@zeetes
Last config spec update 2011-02-25T18:49:37-06:00 by informix.informix@zeetes
Last view private object update 2011-02-25T18:49:56-06:00 by informix.informix@zeetes
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/informix : rwx (all)
Group: lenexa.pd/informix : r-x (read)
Other:                  : r-x (read)
Additional groups: lenexa.pd/RAND lenexa.pd/ccids lenexa.pd/ccos

检测到 SUID 程序不工作

问题不在于操作系统发出有关运行 SUID 程序的错误消息。问题是，即使该程序看起来是 setuid root，但在运行时，该程序实际上并不是 setuid：

Zeetes IX: ls -l asroot
-r-sr-xr-x 1 root informix 24486 Feb 25 18:49 asroot
Zeetes IX: ./asroot id
asroot: not installed SUID root
Zeetes IX:

这是未使用 SUID root 权限安装时 asroot 的输出。在另一台机器上：

Toru JL: ls -l asroot
-r-sr-xr-x 1 root informix 26297 2011-02-27 00:11 asroot
Toru JL: ./asroot id
uid=0(root) gid=1240(rd) groups=1240(rd),1360(RAND),8714(ccusers),8803(ccids),8841(ccos)
Toru JL:

如果程序是使用 SUID root 权限安装的，这或多或少是我期望的输出。

安装信息

两个主要的 VOB 是 tristarp 和 tristarm。在 SUID 正常的机器上（手动完成换行以避免滚动条）：

aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
     (uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)
aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
     (uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5)

在 SUID 不正常的机器上：

aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
     (uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5,nosuid)
aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
     (uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)

这就是恶棍！ （我以为我查看了mount信息。显然。我看的不够准确，或者只在一台机器上 - 正在工作的机器上 - 或其他东西上。）奇怪的是，只有其中之一这两个VOB是用nosuid挂载的；很奇怪。

为什么我们有答案！

谢谢，冯C。

探索

脚本 /etc/init.d/clearcase 和 /etc/clearcase 中为 /opt/rational/clearcase< 下的脚本和程序提供了规定。 /code> 使用文件 /var/adm/rational/clearcase/suid_mounts_allowed 来控制是否允许 SUID；它作为一个具有 root:root:000 权限的空文件存在于两台计算机上。但这里可能潜伏着一些其他至关重要的差异 - 我已经向常驻 ClearCase Guru 询问了这一点。然而，看起来差异更有可能在于两台机器上的配置，而不是某些特定于版本的功能变化。两个版本表面上都支持 nosuid 选项，尽管两个版本都没有明显调用该选项 - 只不过 7.1.1.1 版本设法调用它，而 7.0.1 版本却没有。

原文

We have two machines (under discussion) running ClearCase - different versions of ClearCase. Otherwise, they are about as identical in setup as can be - same Linux x86/64 kernel etc.

On one machine, SUID root programs in the view work as SUID root programs.

On the other machine, SUID root programs in the view do not work with SUID privileges, leading to unexpected results.

The only difference we've spotted so far is:

  • Working view: CC 7.0.1
  • Non-working view: CC 7.1.1.1

I can give the full output of cleartool -version if it matters, but I suspect it won't. These are the first versions listed.

Questions

  1. Is this a known difference between the versions of ClearCase, or is it a configuration item, or something else?
  2. Is it possible to configure the newer version of ClearCase (MVFS) to allow SUID root programs to run 'properly'?
  3. If it is configurable, how do we change the configuration make the new version allow SUID programs?

We have a myriad machines running ClearCase, on a lot of different platforms. There have been rumours that on some machines, our SUID software has to be run 'out of view' to work. Now someone was reporting a bug - and it has taken most of the day to narrow down the differences. The issue addressed in the question seems a plausible explanation. If it is something else, so be it. I still need the hair I lost today back again!

Extra Information

All views are dynamic, not snapshot.

This is the output of cleartool lsview -l -full -pro -cview on the machine where SUID programs do work, running ClearCase 7.0.1:

Tag: idsdb00222108.jleffler.toru
  Global path: /net/toru/work4/atria/idsdb00222108.jleffler.toru.vws
  Server host: toru
  Region: lenexa
  Active: YES
  View tag uuid:6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View on host: toru
View server access path: /work4/atria/idsdb00222108.jleffler.toru.vws
View uuid: 6dac5149.2d7511e0.8c62.00:14:5e:69:25:d0
View owner: lenexa.pd/jleffler

Created 2011-01-31T11:58:11-08:00 by jleffler.rd@toru
Last modified 2011-02-26T22:32:49-08:00 by [email protected]
Last accessed 2011-02-26T22:44:55-08:00 by [email protected]
Last read of private data 2011-02-26T22:44:55-08:00 by [email protected]
Last config spec update 2011-02-26T01:10:36-08:00 by [email protected]
Last view private object update 2011-02-26T22:32:49-08:00 by [email protected]
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/jleffler : rwx (all)
Group: lenexa.pd/rd     : rwx (all)
Other:                  : rwx (all)
Additional groups: lenexa.pd/RAND lenexa.pd/ccusers lenexa.pd/ccids lenexa.pd/ccos

This is the output on the machine where SUID programs do not 'work', running ClearCase 7.1.1.1:

Tag: new.jleffler.zeetes
  Global path: /tmp/jl/new.jleffler.zeetes.vws
  Server host: zeetes
  Region: lenexa
  Active: YES
  View tag uuid:f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View on host: zeetes
View server access path: /tmp/jl/new.jleffler.zeetes.vws
View uuid: f62b7c80.414111e0.9cec.00:14:5e:de:1b:44
View owner: lenexa.pd/informix

Created 2011-02-25T18:40:11-06:00 by informix.informix@zeetes
Last modified 2011-02-25T18:49:56-06:00 by informix.informix@zeetes
Last accessed 2011-02-25T18:50:31-06:00 by informix.informix@zeetes
Last read of private data 2011-02-25T18:50:31-06:00 by informix.informix@zeetes
Last config spec update 2011-02-25T18:49:37-06:00 by informix.informix@zeetes
Last view private object update 2011-02-25T18:49:56-06:00 by informix.informix@zeetes
Text mode: unix
Properties: dynamic readwrite shareable_dos
Owner: lenexa.pd/informix : rwx (all)
Group: lenexa.pd/informix : r-x (read)
Other:                  : r-x (read)
Additional groups: lenexa.pd/RAND lenexa.pd/ccids lenexa.pd/ccos

Detecting that SUID programs are not working

The problem is not that there is an error message from the operating system about running the SUID program. The problem is that even though the program appears to be setuid root, when run, the program is not actually setuid:

Zeetes IX: ls -l asroot
-r-sr-xr-x 1 root informix 24486 Feb 25 18:49 asroot
Zeetes IX: ./asroot id
asroot: not installed SUID root
Zeetes IX:

This is the output from asroot when it is not installed with SUID root privileges. On the other machine:

Toru JL: ls -l asroot
-r-sr-xr-x 1 root informix 26297 2011-02-27 00:11 asroot
Toru JL: ./asroot id
uid=0(root) gid=1240(rd) groups=1240(rd),1360(RAND),8714(ccusers),8803(ccids),8841(ccos)
Toru JL:

This is more or less the output I'd expect if the program is installed with SUID root privileges.

Mount information

The two main VOBs are tristarp and tristarm. On the machine where SUID is OK (wrapping done manually to avoid scrollbars):

aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
     (uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)
aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
     (uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5)

On the machine where SUID is not OK:

aether:/vobs/tristarm.vbs on /vobs/tristarm type mvfs \
     (uuid=b74900ef.814511cf.afee.08:00:09:b1:54:d5,nosuid)
aether:/vobs/tristarm.vbs on /vobs/tristarm.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.151)
charon:/vobs/tristarp.vbs on /vobs/tristarp.vbs type nfs \
     (rw,hard,intr,bg,addr=9.25.149.147)
charon:/vobs/tristarp.vbs on /vobs/tristarp type mvfs \
     (uuid=684ef023.2dd111d0.b696.08:00:09:b1:a4:c5)

And there's the miscreant! (And I thought I'd looked at mount information. Evidently. I'd not looked accurately enough, or only on one machine - the working one - or something.) It is odd that only one of these two VOBs is mounted with nosuid; very odd.

We have an answer why!

Thanks, VonC.

Explorations

There is provision in the scripts /etc/init.d/clearcase and /etc/clearcase for the scripts and programs under /opt/rational/clearcase to use a file /var/adm/rational/clearcase/suid_mounts_allowed to control whether SUID is allowed or not; it exists on both machines, as an empty file with permissions root:root:000. But there may be some other difference that is crucial lurking here - I have asked the resident ClearCase Guru about this. However, it looks as though the difference is more likely in the configuration on the two machines than it is some version-specific change in functionality. Both versions superficially support the nosuid option, even though neither is self-evidently invoking that option - except that the 7.1.1.1 version is managing to invoke it where the 7.0.1 version is not.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（1）

︶￣淡然 2024-10-26 10:40:10

了解以下内容会很有趣：

  • 两种视图都是快照还是动态视图。我认为是动态的，有一个与 MVFS 相关的问题。
  • 'cleartool lsview -l -full -pro -cview' 在两种情况下都会返回什么（在每个视图中执行时，一种情况下 SUID 有效，一种情况下无效），
  • 如果每个视图中的本地路径尝试 SUID 位时视图是相同的（本地路径是视图内的路径，如 /vobs/MyVob/.../path /to/a/directory）

主要是，您是否有确切的错误消息，例如 在此线程中：

我们看到 VOB 在 Linux 和 SunOS 上使用不同的选项进行挂载，特别是，Linux 添加了“nosuid”挂载选项，而在 SunOS 上添加了“setuid”。

这会在 Linux 计算机上进行分布式构建时给我们带来麻烦，因为远程计算机在尝试从其中一个 VOB 执行 suid root 二进制文件时会收到“不允许操作”错误

请参阅 cleartool安装选项：

UNIX 和 Linux：nodev、nosuid、suid。

另请参阅“使用cleartool protected 命令设置粘性位 ”

使用以下语法通过cleartool protected命令正确设置“粘滞位”：

cleartool protect -chmod u=rxs <file>

It would be interesting to know:

  • if both kind of views are snapshots or dynamic views. I suppose dynamic, with an issue related to MVFS.
  • what a 'cleartool lsview -l -full -pro -cview' returns in both case (when executed within each views, one where SUID works, one where it doesn't)
  • if the local path within each view is the same when trying the SUID bit (local path being the path within the view as in </path/toView>/vobs/MyVob/.../path/to/a/directory)

And mainly, do you have an exact error message, like in this thread:

We see that VOBs are mounted with different options on Linux and SunOS, especially, Linux adds a "nosuid" mount option, while on SunOS "setuid" is added.

This causes us trouble during distributed builds on the Linux machines, because the remote machine(s) gets an "Operation not permitted" error when trying to execute a suid root binary from one of the VOBs

See the cleartool mount options:

UNIX and Linux: nodev, nosuid, suid.

See also "Setting the sticky bit using the cleartool protect command"

Use the following syntax to properly set the "sticky bit" using the cleartool protect command:

cleartool protect -chmod u=rxs <file>
回复 原文
~没有更多了~

关于作者

多情癖

暂无简介

0 文章
0 评论
694 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文