[Mageia-dev] RM replacement

Fri Aug 5 14:58:12 CEST 2011

Colin Guthrie a écrit :
+> 'Twas brillig, and andre999 at 05/08/11 06:50 did gyre and gimble:
+>> Luis Daniel Lucio Quiroz a écrit :
+>>> Le Jeudi 04 Août 2011 18:39:35 andre999 a écrit :
+>>>> Luis Daniel Lucio Quiroz a écrit :
+>>>>> Helo,
+>>>>>
+>>>>> As my experience in security field, to make Mageia more available in
+>>>>> enterprise environments, and specially those that are security
+>>>>> paranoid, i'm planning to port SRM.  SRM is a package that does a
+>>>>> "secure" file deleting according some security standards (i dont
+>>>>> remember right now names, i guess it is something in NIST, but that
+>>>>> doesnt matter really).
+>>>>>
+>>>>> My question is, what should be the procedure that when you install srm,
+>>>>> then the normal rm command could be replaced?  i was thinking in
+>>>>> pushing an alias but what other alternatives do i have?
+>>>>>
+>>>>> please comment,
+>>>>>
+>>>>> LD
+>>>>
+>>>> At first glance that sounds like a reasonable approach EXCEPT -- a
+>>>> system-level alias would be over-ridden by a user alias.
+>>>> A user could innocently have an alias such as :
+>>>> alias rm="rm -i"
+>>>>
+>>>> rm is in /bin
+>>>> - /bin/rm could be replaced with a link to srm, but I don't know if that
+>>>> would be considered acceptable.
+>>>> rm would have to be restored if srm were uninstalled
+>>>>
+>>>> - wouldn't a link in /usr/bin/rm be executed first ?
+>>>> Of course that doesn't cover execution with root privileges.
+>>>> An alias in root wouldn't necessarily work, as an admin could
+>>>> inadvertantly
+>>>> replace it with another.  (By loading a new file with some changed
+>>>> alias,
+>>>> for example.)
+>>>> But probably less likely than some user doing the same on their profile.
+>>>>
+>>>> There could be other approaches as well ... :)
+>>>
+>>> You are right! :)
+>>>
+>>> Well another option could be this:
+>>>
+>>> a. we change coreutils to install /bin/rm as  /bin/rm.vanilla (or
+>>> other name,
+>>> that really doesnt matter),
+>>> b. i change srm to install itself in /bin instead of /usr/bin
+>>> c. we place alternatives in both packages to provide /bin/rm, giving
+>>> preference to srm if installed, otherwise it will use rm of coreutils
+>>>
+>>> LD
+>>
+>> That would probably be the ideal approach.  But it might take a while to
+>> get the changes accepted in coreutils.
+>>
+>> Maybe it could be all done from srm ?
+>> On srm install,
+>> a. rename /bin/rm to /bin/rm.vanilla (or rm.original or ?)
+>> b. create /bin/rm link to /bin/srm
+>
+> Definitely not. It's against the commandments: Thou shalt not mess with
+> another packages' files.
+
+ok.  I suspected that.
+It would be nice to have a list of these points for newer packagers.
+
+>> On srm uninstall, we ensure that
+>> a. rm /bin/rm link
+>> b. rename /bin/rm.vanilla to /bin/rm
+>>
+>> Hopefully that could be done reliably, with an uninstall script.
+>
+> No, this is very bad.
+>
+> It's what the alternatives system was designed to do for you, but I
+> really don't think that something as fundamental as rm should be messed
+> with in this way as I mentioned in my own email.
+>
+> srm is an add on userspace tool. To implement secure deletes properly,
+> you would want support at a lower level (i.e in the kernel/fs).
+
+makes sense.
+
+> I think srm should just be a tool people use explicitly when they want to.
+
+When I think about it, deleting with a pattern instead of just zeros is 
+probably only advantageous when a disk is being disposed of -- in which case 
+srm being a userspace tool is not a disadvantage.
+
+> Col
+>
+
+-- 
+André
+