Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize access needs a better way of removing +w on system folders #60

Closed
igoraj opened this issue Jun 2, 2015 · 2 comments
Closed

Comments

@igoraj
Copy link
Contributor

igoraj commented Jun 2, 2015

I came across two different issues with symlinks (that already existed on VM images I was deploying)

  • a VM image that had symlink /usr/bin/X11 targeting itself X11 -> . causing the following error:
Error: /Stage[main]/Os_hardening::Minimize_access/File[/usr/bin]: Failed to generate additional resources using 'eval_generate': Too many levels of symbolic links - /usr/bin/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/X11/cc
  • a VM image that had broken symlink (target did not exist)
Error: /Stage[main]/Os_hardening::Minimize_access/File[/usr/bin]: Failed to generate additional resources using 'eval_generate': No such file or directory - /usr/bin/vmware-user-wrapper

I agree that the image itself should have this things fixed, but it might be worth considering a better approach that would deal with this type of issues in this module.

spielkind added a commit to TelekomCloud/puppet-os-hardening that referenced this issue Jun 24, 2015
@spielkind
Copy link
Contributor

Wouldn't call it a fix, but maybe a workaround or interim solution (at least for the first case).

rooprob added a commit to rooprob/puppet-os-hardening that referenced this issue Aug 27, 2015
Issue: dev-sec#60

From this page ubuntu linking ```/usr/bin/X11 -> .``` is by design:
http://askubuntu.com/questions/191654/why-are-there-infinitely-many-x11-subdirectories-in-usr-bin-x11

This modification says ```links => follow``` is inappropriate.  The
specification of directories to apply this file resource is good, so it
should cover the desired scope: that any files contained herein should
be set as per the resource. Any files outside, including symlink targets
should be untouched.  Any files which are symlinked to other files
inside will be caught, and any symlinks, self-referential or otherwise,
will be ignored. This would resolve issue 60.
@mcgege
Copy link
Member

mcgege commented Jan 13, 2018

Should be fixed now by #116

@mcgege mcgege closed this as completed Jan 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants