Doesn't protect symbolic links

Bug #899721 reported by Alex Mason on 2011-12-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

In version 0.6 a bug was fixed (and presumably the not -l flag added to the check) regarding symbolic links.

I believe it should protect symbolic links if that was the full path specified under the principle of least astonishment.

Take this scenario:

OS X symlinks /etc, /tmp/ and /var to directories residing in /private

Given the default blacklist includes /var you would expect a sudo rm -rf /var to skip the file. But as it's a symlink, safe-rm will give it a pass and the symlink is deleted.

I understand not wanting all symlinks to be protected, but surely if the original full path of the blacklisted file i.e /var is itself a symlink, then in that situation it should honour it and not allow it to be deleted?

Changed in safe-rm:
status: New → Triaged
importance: Undecided → Low
François Marier (fmarier) wrote :

The reason why I excluded symlinks from the list of protected paths is that it used to be impossible to delete symlinks like this one:

  ln -s /usr/lib ~/system-lib

because safe-rm was checking the true path of the file/directory (i.e. after de-referencing the symlink) against the blacklist. I figured that symlinks are not hard to re-create anyways (you never lose the underlying file/directory if you delete one) so they were probably not worth protecting.

I can see that if we were to change that this check:

  IF path is a symlink AND non-dereferenced symlink is in the blacklist

then we could bring back protection for symlinks. Can you think of any problems with that approach?

Alex Mason (seliquity) wrote :

No, that approach sounds perfect

François Marier (fmarier) wrote :

There is a possible complication with this: the realpath function is what we use to convert something like "../../usr/lib" to "/usr/lib" and that's also the function that de-references symlinks.

If we stop using it (with symlinks) to avoid de-referencing symlinks, then only absolute symlinks will be protected, not the ones in relative paths.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers