Clearcase: How to control whether SUID programs work in a view or not?

Question

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.

Answer 1

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>