'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/]