Re: [Ltib] World writable dirs in ltib

[Svein Seldal]

Stuart Hughes wrote:

> Yes, I think this is possible, but care would have to be taken.  The 
> single biggest problem is the initial bootstrapping of the 
> /opt/{ltib,freescale} area.  This is what needs the sudo /bin/rpm entry. 
>  The reason being that you have to allow a user to create a common 
> directory in /opt that they would not otherwise have permission to do. 
> Maybe a compromise would be to change the sudo test in LTIB to say 
> something like:
>
> To initially install LTIB you must get a sysadmin who has sudo /bin/rpm 
> permission to install the common areas, or you will need to have this 
> permission yourself.   Once installed, to use LTIB as a user, you only 
> need sudo /opt/ltib/usr/bin/rpm permission.

I previously did an investigation of the initial hostcf bootstrap and as 
far as I understand it consists of 5 parts:
    1) Using host's rpmbuild to build rpm-fs package
    2) Install rpm-fs using host's rpm
    3) Update rpm-fs using opt rpm
    4) Build other host packages using opt rpmbuild
    5) Install other host packages using opt rpm

Now, the intersting thing is that sudo /usr/bin/rpm is ONLY needed for
item no 2. So why setup /usr/bin/rpm with NOPWD just for this once? Just 
let the user enter his sudo password.

I would appreciate one thing though: Prior to running sudo, I'd more be 
more comforted(?) by having a text message telling the user what is 
about to happen. Something like:

"Warning: I am about to run /usr/bin/rpm as root to install
  /tmp/rpm-nosse1/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm
under /opt/ltib. I have checked the rpm to make sure it does not clobber 
your system.

sudo rpm --root / --dbpath /tmp/rpm-nosse1/rpmdb --ignorearch -ivh 
--force --nodeps --excludedocs  --define '_tmppath 
/home/nosse1/vitalsim2/imx/upstream/ltib.build/tmp' 
/tmp/rpm-nosse1/RPMS/i686/rpm-fs-4.0.4-1.i686.rpm
"

It may seem obvious, but I were not aware of the clobber checks until I 
manually skimmed through the ltib script!

Coming back to the hostcf building process: When the rpm-fs package is 
installed into /opt using the host's rpm, you don't actually need to 
install any of the other host packages to be able to build them.

I made a test the other day, were I didn't install anything, just build.
This way I got a handful of .rpm files in /opt/ltib/src/rpm/RPMS/...
which could be installed in one singular shebang. I use this to
distribute binary host tools across different homogeneous machines. See
the attached script. (For that scenario it would have been nice with a 
--build-only feature of --hostcf.)


> This would allow you to limit the sudo hole to just 
> /opt/ltib/usr/bin/rpm.  As we build this, we could control the base 
> prefixes into which it can install.

Are there any limitations inside the rpm application to limit where it
can install packages?  E.g.

$ sudo /opt/ltib/usr/bin/rpm --root / --dbpath /var/lib/rpm --prefix /
-ivh some.rpm

is still possible and destructive to the system, right?

At some point it boils down to trust. If we make a security auditer, who
audits the auditer? So in practice this isn't a problem I guess.

I think the most likely mistake is if a user manually runs
"/opt/ltib/usr/bin/rpm -ivh faulty_pkg.rpm". Since the command promt
lines for rpm operations inside ltib are very long, I doubt this will be
done manually though.


- Svein

install-ltib-host.sh
Description: Bourne shell script