----- 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!
--
James A. Peltier
Manager, IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone : 778-782-6573
Fax : 778-782-3045
E-Mail : jpeltier@xxxxxx
Website : http://www.sfu.ca/itservices
“A successful person is one who can lay a solid foundation from the bricks others have thrown at them.” -David Brinkley via Luke Shaw
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
