Just like the title says, is this possible?
Say I have a file named
rm isn't going to do the job, and if I don't have the ability to install
shred or some other tool, can I securely erase this file "by myself"?
Even with such tools, whether such a method of secure erasing works, depends on the underlying filesystem.
If you are using a modern Copy On Write based filesystem, these tools will not work at all, since they would not write to the previous blocks used by the file.
If you like to do secure erasing, you would either need support for that feature built into the filesystem, or the filesystem would need to implement an interface that allows to retrieve the disk block numbers for a file. The latter method however is a security risk and can only be supported for a privileged user.
Bear in mind that how well file level erasing works in practice depends a great deal on the underlying file system and drive hardware. Modern copy-on-write (journalled) filesystems such as ext4 do not "overwrite" file data in the original location, which makes most file-oriented erase tools, such as
wipe, far less useful that they were in years past. SSDs have similar characteristics at the block level, see https://www.howtogeek.com/234683/why-you-cant-securely-delete-a-file-and-what-to-do-instead/
So we would have to assume you are doing this on an old fashioned magnetic hard drive and a non-journalled non-COW filesystem. Perhaps acceptable assumptions in the 1990s, but are they realistic in 2020?
Then, "basic Unix/linux cmmand line tools" seems vague.
shred is part of coreutils, which is a set of "basic Unix/Linux command line tools". So at one level, use
shred and you meet your requirements!
shred -zu FILENAME
Otherwise, you seem to be asking for a way to overwrite the contents of an existing file (perhaps repeatedly), and then delete it, "by myself". You could use
dd to copy zeroes to the file, but
dd is part of coreutils too, so why in practice that is any more "by myself" than using
shred is debatable.
Does "by myself" mean using only sh or bash internal commands?
Because this problem is typically important, it may not be relevant how contorted a solution is.
But if it's important, this actually may be a practical solution.
When a tool that safely deletes a file exists, it practically needs to know the file system. So a tool that can do this in general practically can not exist.
But we do not need to make assumptions about the file system.
We start with removing the file we want to be forgotten completely, on the file system level, with a normal rm command:
$ rm -f myfile.dat
Now, it no longer exists in the file system. But we know that the content still exists on the storage under the filesystem - because removing it takes time. And it is possible, even common, that the filesystem itself still has information about where it is.
We want to have a file system that has no traces of the file left. And seen from the file system surface, there already are no traces left!
Now, we create a suitable new, empty filesystem elsewhere.
And then, we make a copy of the old filesystem on the file level, where it is already clean!
We still do not know much about where information from the file may still be, but what we know is that it is in the storage under the old filesystem. We just ignore that the old filesystem still exists, and clean the storage up by writing pseudorandom bytes from
/dev/urandom to it.
That's enough to delete the data.
If you still do not feel sure it's gone, do not try to write actual random numbers from
/dev/random. There is not much randomness that can be read from it, and other software need some randomness too.
Just repeat overwriting it with pseudorandom numbers from
/dev/urandom until you relax.
Then, you can move the new filesystem as a whole to the original storage place. Done.