[Mageia-dev] RM replacement

Fri Aug 5 18:00:02 CEST 2011

Le Vendredi 05 Août 2011 08:58:12 andre999 a écrit :
+> 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
+Good point
+