Many users use portage from within cron (for instance to update the
portage tree or even automatically update their system). As such, we
allow to run portage from the (system) cronjob domains.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
We allow portage to call gpg. However, this requires that the location
where the trustdb is stored is marked as a read/write type. The default
location used within Gentoo is /etc/portage/gpg, which would lead to
portage_conf_t. However, this type should remain a read-only type.
As such, we introduce a type called portage_gpg_t for this location and
grant portage_fetch_t the necessary rights on this type.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Enhance portage_fetch_t from an application type to a domain. Introduce
the proper portage_fetch_exec_t and add the necessary privileges to the
domain definition to allow portage_fetch_t to be used by Portage
management utilities like layman and emerge-webrsync.
We enhance portage_domtrans() to include portage_fetch_t support.
Providing a different interface (portage_fetch_domtrans) is possible
too, but since every application and role that needs to deal with
portage needs to deal with the fetching as well, and vice versa, we keep
this in portage_domtrans.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The gcc-config application uses some functions (from
/etc/init.d/functions.sh) which are simple wrappers on top of
/sbin/rc. Since this script is sourced and the functions executed
from within gcc_config_t, we allow gcc-config to execute /sbin/rc
without transitioning.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Portage supports the use of proxy systems (which usually run on port 8080)
for the fetching of software archives.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
Portage supports the notion of "live ebuilds", which are packages that, when
installed, update a repository checkout on a specific location. This means
that a few portage-related domains need to have manage_* privileges on that
location whereas they usually have much more limited rights (when live
ebuilds aren't used).
To support live ebuilds, we introduce another label called portage_srcrepo_t
for those specific locations where the "higher" privileges are needed for,
and grant the proper permissions on the compile domains (like
portage_sandbox_t) to manage the checkouts.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
When users want to use NFS mounted portage tree, distfiles, packages and
other locations, they need to use the proper context= mount option. However,
in the majority of cases, the users use a single NFS mount. In such
situation, context= cannot be used properly since it puts a label on the
entire mount (whereas we would then need other labels depending on
subdirectories).
Introducing a boolean "portage_use_nfs" which, when set (default off),
allows the necessary portage-related domains to manage files and directories
with the nfs_t label.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
During the installation of for instance java-config, Portage wants to set
its default file creation context to root:object_r:portage_tmp_t which isn't
allowed:
creating /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/etc/revdep-rebuild
copying src/revdep-rebuild/60-java -> /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/etc/revdep-rebuild/
running install_egg_info
Writing /var/tmp/portage/dev-java/java-config-2.1.11-r3/temp/images/3.1/usr/lib64/python3.1/site-packages/java_config-2.1.11-py3.1.egg-info
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
cp: failed to set default file creation context to `root:object_r:portage_tmp_t': Permission denied
...
ERROR: dev-java/java-config-2.1.11-r3 failed:
Merging of intermediate installation image for Python ABI '2.6 into installation image failed
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
During installation of system packages like python, ustr, ... the
portage_sandbox_t domain requires ptrace capabilities.
If not allowed, the following error is returned:
/sbin/ldconfig -n /var/tmp/portage/dev-libs/ustr-1.0.4-r1/image//usr/lib64
ISE:_do_ptrace ^[[0mptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Permission denied
/usr/lib/libsandbox.so(+0x3812)[0x7535af0ca812]
/usr/lib/libsandbox.so(+0x38a3)[0x7535af0ca8a3]
/usr/lib/libsandbox.so(+0x5595)[0x7535af0cc595]
/usr/lib/libsandbox.so(+0x5a87)[0x7535af0cca87]
/usr/lib/libsandbox.so(+0x68de)[0x7535af0cd8de]
/usr/lib/libsandbox.so(execvp+0x6c)[0x7535af0ceb3c]
make(+0x1159e)[0x337b918159e]
make(+0x11eec)[0x337b9181eec]
make(+0x12b34)[0x337b9182b34]
make(+0x1e759)[0x337b918e759]
/proc/5977/cmdline: make -j4 install
DESTDIR=/var/tmp/portage/dev-libs/ustr-1.0.4-r1/image/ HIDE=
libdir=/usr/lib64 mandir=/usr/share/man SHRDIR=/usr/share/doc/ustr-1.0.4-r1
DOCSHRDIR=/usr/share/doc/ustr-1.0.4-r1
This seems to be during a standard "make install" of the package but part of
Portage' sandbox usage (above error for ustr, but packages like python exhibit
the same problem.)
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The installation of the wireshark package (and perhaps others) requires
portage setting file capabilities (through the setcap binary).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
The alsactl binary is often installed in /usr/sbin instead of /sbin (not a
necessity to start up the system). Used in distributions such as Gentoo,
Slackware and Arch.
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
