source: ProjectBuilder/devel/pb-doc/SECURITY@ 1179

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 geing 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 and 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.conf 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/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 (Commande extraite d'un fichier de conf local => Potential Security issue for RM)
sudo /bin/date

The default /etc/sudoers file created for VM/VE contains:
Defaults:pb env_keep += "http_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 in some Linux distributins 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