Mark Dominus on 6 Dec 2007 16:42:28 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] "What's a File?" talk slides now online


Art Alexion:
> I was wondering about what you said about Directories
> (http://perl.plover.com/classes/files/samples/slide013.html).  Is it possible
> to edit the directory directly so as to "obscure" files a degree more
> securely than the leading dot?

On old systems, you could edit a directory by opening the directory
file directly; you could use "cat" to print out the binary data, and
so on.  On more modern systems, that's forbidden.  Of course, root can
always open up the raw disk device and twiddle the data directly.

But I'm not sure exactly what you're getting at here.   

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?

___________________________________________________________________________
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