[Mageia-dev] RM replacement

[Luis Daniel Lucio Quiroz]

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