Security infos ============== In order to work correctly, pb needs some root access to perform certain activities. This is done by calls to sudo. However, by default all actions are performed with an unpriviledge user (the one using pb or the pb user if working on VM/VE/RM) Security is not considered a constaint when pb is generating the build environment itself, such as for VM and VE. So, in these cases, the sudo configuration allows the pb user to do all commands without password in the VM or to perform locally all actions for the VE management, by being granted full local access. However, when using pb with RM, as the systems may pre-exist and be used for other tasks, a strict analysis of the actions performed is required, in order to restrict precisely the commands called with sudo priviledges, as these are done without password request to automate generation. In the Distributions.pm module there are sudo calls, corresponding to the abilty to configure automatically additional repositories. That feature may not be used on RM or solved manually without problem. In case this is used, and sudo isn't configured accordingly, then the additional repo will NOT be added and the build will probably fail. In the default pb.yml main configuration files, parameters for osupd and osins for the various distributions call sudo to make the installation of missing packages. These calls are done as 'pb' user by default (or the account configured as rmlogin in the configuration file). In case this is used, and sudo isn't configured accordingly, then the additional required packages will NOT be added and the build will probably fail. For RM, we may consider that all required packages for the build are already installed on the system, or give rpm/yum/dnf/apt/urpmi/zypper... sudo rights to the build account manually. Recommended for a manual setup (not using rmsetup): Add manually to your system sudo access for the pb account to the local package install and update command such as /bin/rpm e.g: cat >> /etc/sudoers << EOF pb localhost=/bin/rpm NOPASSWD: EOF In order to handle correctly RM, we need to consider they are well managed, and already have NTP configuration correctly setup. You may also allow pb to setup date on your RM, if you consider it harmful. pb will use the configuration parameter All: sudo $vntpcmd $vntp (Command extracted from a local conf file => Potential Security issue for RM) sudo /bin/date The default /etc/sudoers file created for VM/VE contains: Defaults:pb env_keep += "http_proxy https_proxy ftp_proxy" Defaults:pb !requiretty pb ALL=(ALL) NOPASSWD:ALL For VM, we have just one sudo call that is required for pb to halt the VM. They are launched in the VM. Again, no special security feature is provided, as we consider that the pb account should do what he wants in the VM. Please report to dev team any concern you have around this. sudo $hpath/halt $hoption For VE, we have this list of additional sudo calls that are required for pb to work correctly. They are launched on the main system, but target the chroot. Again, no special security feature is provided, as we consider that the pb account should do what he wants in the chroot. But some commands need to be executed from the host environement, and thus should be looked at closely anyway. Please report to dev team any concern you have around this. shcmd: sudo /usr/sbin/chroot $tpdir shcp : sudo /bin/cp -r (These 2 commands are used a lot to setup the chroot correctly) sudo chown -R $mac $tdir sudo chown $UID $ENV{'PBBUILDDIR'}/pbgen-$ENV{'PBPROJVER'}-$ENV{'PBPROJTAG'}.$$" sudo tar cz -C $tpdir -f $vepath->{$ENV{'PBPROJ'}}/$odir-$over-$oarch.tar.gz . sudo rinse|rpmbootstrap|mock|debootstrap sudo cp /etc/hosts $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'}/$pbos->{'arch'}/etc/hosts sudo chmod 755 $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'} $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'} $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'}/$pbos->{'arch'} sudo rm -rf $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'}/$pbos->{'arch'} ; sudo mkdir -p $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'}/$pbos->{'arch'} ; sudo tar xz -C $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}/$pbos->{'version'}/$pbos->{'arch'} -f $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}-$pbos->{'version'}-$pbos->{'arch'}.tar.gz sudo /bin/mount -t proc /proc /proc sudo /bin/umount /proc sudo rm -f $vepath->{$ENV{'PBPROJ'}}/$pbos->{'name'}-$pbos->{'version'}-$pbos->{'arch'}.tar.gz Here is a list of commands called locally to build on some Linux distributions special cases: For gentoo: sudo sh -c 'echo PORTDIR_OVERLAY=\"$ENV{'HOME'}/portage\" >> /etc/make.conf' For Slackware (TBC): sudo /sbin/makepkg -p -l y -c y $pbpkg