Doesn't protect symbolic links

Bug #899721 reported by Alex Mason
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
François Marier

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
Revision history for this message
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?

Revision history for this message
Alex Mason (seliquity) wrote :

No, that approach sounds perfect

Revision history for this message
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.

Changed in safe-rm:
milestone: none → 1.1.0
assignee: nobody → François Marier (fmarier)
status: Triaged → Confirmed
Changed in safe-rm:
status: Confirmed → In Progress
Changed in safe-rm:
status: In Progress → Fix Committed
Changed in safe-rm:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.