Hello, I''m in the process of setting up puppet for my installation. One of the things I''m tasked with doing is making sure that all network mounts are nosuid. I''m not entirely sure how to do this. I don''t think I want the ''mount'' type; I''m not trying to define the mounts themselves in puppet. Augeas, meanwhile, does not seem to the ability to loop through contexts to use the onlyif option, though I could set up checks for each entry in fstab, i.e. using context /files/etc/fstab/ 0, /files/etc/fstab/1, etc. I don''t see another option that will work with what I''m looking for. Can anyone give me any pointers on how to make this work? Thanks, Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ben Lavender wrote:> I''m not trying to define the mounts themselves in puppet.Why not? -scott --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Jul 7, 6:17 pm, Scott Smith <sc...@ohlol.net> wrote:> Ben Lavender wrote: > > I''m not trying to define the mounts themselves in puppet. > > Why not?Because: * I do not see the point in doing necessarily per-machine configuration centrally. One day when it''s all on a SAN, that might change. * Since these are virtual machines, any ''correct'' config also involves correctly managing LVM/disk images/xen config on the host, none of which are currently fully supported * The security policy I am trying to implement does not really concern itself with local disks this way. * As I am trying to implement a security policy, even if I managed mounts in puppet, I would still have the problem that it was possible another administrator had defined an NFS mount that was not nosuid. We''re only just starting with puppet and it''s not okay at this stage to have puppet wipe out non-puppet mounts/config; we''re 200 machines into it and growing and there is a lot of custom config/applications across those machines. Ben> -scott--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ben Lavender wrote:> On Jul 7, 6:17 pm, Scott Smith <sc...@ohlol.net> wrote: >> Ben Lavender wrote: >>> I''m not trying to define the mounts themselves in puppet. >> Why not? > > Because: > * I do not see the point in doing necessarily per-machine > configuration centrally. One day when it''s all on a SAN, that might > change. > * Since these are virtual machines, any ''correct'' config also > involves correctly managing LVM/disk images/xen config on the host, > none of which are currently fully supported > * The security policy I am trying to implement does not really > concern itself with local disks this way. > * As I am trying to implement a security policy, even if I managed > mounts in puppet, I would still have the problem that it was possible > another administrator had defined an NFS mount that was not nosuid. > > We''re only just starting with puppet and it''s not okay at this stage > to have puppet wipe out non-puppet mounts/config; we''re 200 machines > into it and growing and there is a lot of custom config/applications > across those machines.Hmm, puppet concerns itself "only" with "resources". "Ensure that nfs mounts are nosuid" is no resource. A script that "ensures that nfs mounts are nosuid" would be a resource and that should probably be executed by a kind of regular security check run and not your configuration management tool. Regards, DavidS --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ben Lavender wrote:> * I do not see the point in doing necessarily per-machine > configuration centrally.That is exactly what Puppet is awesome for.> * As I am trying to implement a security policy, even if I managed > mounts in puppet, I would still have the problem that it was possible > another administrator had defined an NFS mount that was not nosuid. >You would also have the problem if another administrator decided to disable Puppet for a specific node. If you''re in a multi-administrator environment, peer reviewing Puppet manifests should be standard, so enforcing such a policy during that process would cost far fewer resources than the polling hundreds of machines to ensure the guidelines are followed, not to mention the time taken to implement it in Puppet. If you do determine that such a policy should be enforced programatically, David is right--it should not be in Puppet.> We''re only just starting with puppet and it''s not okay at this stage > to have puppet wipe out non-puppet mounts/config; we''re 200 machines > into it and growing and there is a lot of custom config/applications > across those machines. >Understandable, but IMO we should do our best to not subvert, overturn or reimplement the underlying capabilities of software (especially something as flexible as Puppet) as we begin to implement it. -scott -- scott@ohlol.net http://github.com/ohlol --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---