[Mageia-dev] RM replacement

[andre999]

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é