On 10/07/2019, Marc Espie <es...@nerim.net> wrote:
> On Tue, Jul 09, 2019 at 11:16:24PM +0200, ropers wrote:
>> On 09/07/2019, Stuart Henderson <s...@spacehopper.org> wrote:
>> > The lsof port didn't display filenames. That information is not
>> > available on OpenBSD (and is not trustworthy on other OS either;
>> > files could have been moved/replaced since opening).
>>
>> Interesting. Thanks.
>> Is the (un)availability of filename info a feature of the filesystem
>> (ext2/3/etc vs FFS) or of the OS?
>> Are there security implications to this info being available/unavailable?
>
> This information is actually meaningless, on *any* Unix-like OS.
>
> You've got data on the disk. That data is accessible through a file
> descriptor. That file descriptor may or may not correspond to a file name.
>
> The following is perfectly okay in unix:
>
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> unlink("/tmp/myfile");
>
> there. You've got a fd with no name attached to it.
>
> similarly:
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> rename("/tmp/myfile", "/tmp/myfile2");
>
> there. What's the fd name ?
>
> or
> fd = open("/tmp/myfile", O_RDWR|O_CREAT|OTRUNC, 0666);
> link("/tmp/myfile", "/tmp/myfile2");
>
> do you return myfile or myfile2 ?
>
> you could keep some correspondence between fds and file names, but it
> might get out of date, or be meaningless.
>
> You've got this one feature: fstat(2) will give you
> dev_t st_dev; /* inode's device */
> ino_t st_ino; /* inode's number */
> from which you could walk the device and retrieve things
> (and actually it's very useful to uniquely identify files on a system)
>
> And also, there's no guarantee that what information you determine will
> be valid for any amount of time, as files may be renamed.
>
> Guess what ? This is exactly the info fstat(1) displays. And not more,
> with the exact same caveats in its manpage, though in terser fashion.
I wouldn't say the file name information is "meaningless". On Linux,
if a program opened and then unlinked a file, but you still remember
the file name,
then you can still find the file by grepping for its former name,
because the system remembers that too, so long as it's not been
fclose'd yet -- subject to "terms and conditions" like you describe.
We could perhaps think of the former filename as metadata about the
inode; metadata that might or might not get obsoleted before the file
is fclose'd.
It's not a useless feature, but it won't save your bacon in all cases,
because like you showed us above, the system might have "moved on" and
done something else in the meantime. [1]
Whether this is a feature OpenBSD could also implement I'm not in a
position to say, but that doesn't make the feature useless. I'm just
comparing and contrasting, and this has made things clearer to me,
also thanks to some of the replies here.
Ian
[1] Strictly by way of loose comparison: Just because unlinked and
fclose'd files may be well and truly gone from the disk by the time
you use foremost to search for them
<http://ports.su/security/foremost>, doesn't mean that foremost's
ability to sometimes still recover what you want is useless either.
Post-unlink recovery-enabling features have their uses; one just
should rely on them working 100% of the time.
