So start with rpm. Nothing whatsoever stops you from inventing
escalation scenarios and filing as many CVE's as one wishes.
No I don't care to be specific. If you don't understand that
externally created hardlink's are external to package management,
and should be dealt with
If you _REALLY_ want to stop escalation, then wipe the
blocks of erased files before calling unlink(2). Destroying
the content preventing any possibility of an exploit no matter
what privileges are attached to the inode. Even simpler would
be calling ftruncate, though I dare say you will find certain
libraries that are unhappy having ftruncate(2) called
while in use won't be happy.
Attacks against dpkg and anecdotal evidence regarding
your gutsy instestinal fluids are utterly irrelevant.
So start with rpm. Nothing whatsoever stops you from inventing
escalation scenarios and filing as many CVE's as one wishes.
No I don't care to be specific. If you don't understand that
externally created hardlink's are external to package management,
and should be dealt with
If you _REALLY_ want to stop escalation, then wipe the
blocks of erased files before calling unlink(2). Destroying
the content preventing any possibility of an exploit no matter
what privileges are attached to the inode. Even simpler would
be calling ftruncate, though I dare say you will find certain
libraries that are unhappy having ftruncate(2) called
while in use won't be happy.
Attacks against dpkg and anecdotal evidence regarding
your gutsy instestinal fluids are utterly irrelevant.