On Tue, 2005-06-07 at 23:58 -0600, Bob Proulx wrote:
> Marco Colombo wrote:
> > If you live in a hostile environment, make your buildroot in $HOME/tmp,
> > which is likely to be already protected, instead of /var/tmp.
>
> Both /tmp and /var/tmp will be protected with the +t bit.
How would the +t prevent people from reading things or executing suid
files or adding content to writable directories/files?
> > Actually, setting %_tmppath in .rpmmacros could be a good idea, so
> > that you can leave the .spec unchanged (and other tmp files will be
> > created in your home tmp as well).
>
> That is fine. That is the whole point of using a configurable macro.
>
> > Building in /var/tmp but having to closely review your %install scripts
> > to pay attention to permissions because of a hostile environment doesn't
> > make much sense to me. You'll have to do that for every .spec you build
> > from!
>
> If you work in a hostile environment then of course you need to take
> extra care. But by default with +t set on /var/tmp and a "normal"
> umask of 022 then other users will not be able to mess with your
> buildroot.
See above. Umask is useful only if:
* you know nothing in the Makefile changes the permissions when
executing make install;
* you know nothing in the %install section of the spec file
changes permissions either.
*
If you build only packages you wrote from .spec you wrote, that might be
the case. If you're building random rpms, you can't trust the Makefile
and the %install script. Some people like, with reasons, to set their
permissions right in the buildroot. The whole point is that the
buildroot may stay there for days. What about a suid executable owned by
_you_ and executable by all?
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
