[2191] in Release_7.7_team
Re: Minutes of 2000-03-29 meeting
daemon@ATHENA.MIT.EDU (Robert A Basch)
Fri Mar 31 19:06:12 2000
Message-Id: <200004010006.TAA395693@aupair.mit.edu>
To: Greg Hudson <ghudson@MIT.EDU>
cc: release-team@MIT.EDU
In-Reply-To: Your message of "Wed, 29 Mar 2000 15:28:22 EST."
<200003292028.PAA15373@small-gods.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 31 Mar 2000 19:06:06 -0500
From: Robert A Basch <rbasch@MIT.EDU>
> We can into a problem yesterday with their new capabilities model
A bit more info...
For IRIX 6.5, SGI added an implementation of the POSIX capabilities
model, which provides for finer-grained control of process privileges.
This is similar to the privileges model used by VMS, if you're familiar
with that. The idea is that a process can be granted specific privileges
("capabilities") to perform functions without needing access to root or
other system accounts. In the SGI implementation, users are granted
such privileges via the /etc/capabilities database (none if they have
no entry in the database). Capabilities can also be assigned to
executables, analogous to setuid programs. IRIX is now configured with
both capabilities and the familiar "must be superuser" models enabled.
There are actually two problems we stumbled into:
1) Our login program might inherit a non-empty capabilities set; currently
it will pass them down in turn to the user process.
2) The SGI compiler apparently uses LD_LIBRARY_PATH internally to locate
its own shared libraries, but one of the programs called checks to see
if any capabilities are set, and ignores LD_LIBRARY_PATH if so. The
path it falls back to, though, does not include /usr/lib32/cmplrs, which
is where the required be.so library lives. In short, you can't compile
when any capabilities are set.
I will submit patches to fix problem 1 by properly initializing the
user's capability set at login. I think we should also add a user-less
/etc/capability file to the release, just to be safe. (It's an IRIX
config file, so the OS checker ignores it).
Problem 2 is clearly an SGI bug, which I have reported to them. (They
don't seem to consider it a high-priority problem, but we probably don't
care once our login inits things properly).
Bob
