[Mageia-dev] RM replacement

Fri Aug 5 12:17:50 CEST 2011

'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.
+
+> 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).
+
+I think srm should just be a tool people use explicitly when they want to.
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+