| Art Alexion on 6 Dec 2007 17:02:11 -0000 |
|
On Thursday 06 December 2007 11:41:42 Mark Dominus wrote: > But I'm not sure exactly what you're getting at here. That's OK, because you have answered my question. What I envisioned was opening the directory as an editable file, not renaming, but deleting the link to obscure the file. My theory was that the file would still exist because the inode data that you described would still exist, but the file could not be opened because it had no name. I could then keep the link data off the computer. If I wanted to open the file, I could re-edit the directory and add the link. I figured this would not be safe from someone with forensics scanning expertise, but from 99.9% of other users, including those who know about standard hidden dot files. What I didn't anticipate was that fsck on boot would ruin this scheme for me. > > > Whatever name you give the link, anyone who has read permission on the > directory will be able to read the links from the directory and see > the name. And if you somehow break that, then it'll be broken for > everyone, including you, and you won't be able to access the file. > > It is possible to create a file that is still allocated, but which has > no links in the filesystem. But you wouldn't be able to open such a > file, because it has no name. And the "fsck" program, which normally > runs at boot time, looks for exactly this situation, and if it finds > such a file, it relinks them into the /lost+found directory. (It > doesn't know the name, of course, since the name was in the link, and > there is no link. So it names it something like "#142857", where > 142857 is the i-number.) So your hidden file would soon reappear. > > It sometimes happens that one has a link that contains a "/" or a null > character, both of which are forbidden. (Such links sometimes appear > as a result of interactions with other OSes, on which those characters > are not forbidden.) Unix processes can't open such files. For > example, suppose your home directory contains a link for the name > "a/b". Attempting to open "a/b" causes the kernel to look for a > subdirectory "a" with a link "b", not the same thing. So the "a/b" > file is wholly inaccessible. The only thing you can do with it is to > edit the link manually to fix the name, or smash the inode structure > with a program like "clri", which will cause the broken link to be > cleaned up by fsck the next time it is run. > > Maybe I didn't get close to whatever you had in mind. Can you elaborate Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|