----- Original Message ----- | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | On 09/25/2013 12:35 PM, James A. Peltier wrote: | > Hi All, | > | > I'm looking for input as to how I may restrict some post commit | > hooks by | > way of SELinux or some other mechanism. Here's a description of | > the | > problem that I need to solve. | > | > I have a source code server that support SVN and soon git. The | > server has | > no actual users on it and we use CAS with Apache basic | > authentication to | > authenticate and authorize users access to the repository. This | > server | > mounts two NFS shares, one for the mirror environment for HTTP | > based | > installations and another NFS share for our Puppet environment. | > There is a | > corresponding source repository and NFS share for each "user" of | > the system | > as well as corresponding NFS shares for mirror and puppet. All the | > content | > is owned by the user Apache. | > | > Each time a user commits scripts are run to check this code out of | > the | > source code server and into a respective | > | > /mirror/<repotype>/<reponame> /puppet/<repotype>/<reponame> | > | > But there are other bits of code that the end user would like to | > also be | > able to run, such as generating group information based on the | > content of a | > file that was committed manual pruning of some arbitrary data and | > other | > things that I don't want to account for in code. Essentially | > allowing them | > to extend the system further for their needs. | > | > This means that I need to ensure that a user isn't able to run code | > like rm | > -rf /etc/password or rm -rf /{mirror,puppet}/* which would | > essentially ruin | > everyone's data. What I essentially would like to do is ensure that | > if | > someone were to attempt to run any of the third party code that the | > permissions for that run would be within the context of their own | > areas so | > that the most damage they could do is wipe out the content of their | > /mirror/<repotype>/<reponame> & /puppet/<repotype>/<reponame> while | > not | > having to setup and destroy a (potentially) large chroot | > environment each | > time the script is run. | > | You can do everything you want EXCEPT, NFS Does not yes support | labels. You | could prevent a user from touch any of the OS files but not from | writing to | the nfs shares.
Ya, that's what I thought too from my research. It looks like i'm going to have to go with plan B which is to mount the NFS shares for each user repository type and repository name somewhere so that that mount point becomes their root location
mount <mirror location> /mnt/repo_type/user/mirror mount <puppet location> /mnt/repo_type/user/puppet
and then have the scripts only point of reference be from /mnt/repo_type/user . This could potentially mitigate the problem in a similar fashion. Always good to get others ideas though. Thanks Dan!