Jim Paris wrote:
>
> > Therefor it's totally of no influence what you do with the original
> > directory permission. File access has nothing to do with directory
> > permissions...!
>
> Right. However the whole point of this discussion is that that is a
> non-obvious point, there was no other way that the user could have
> opened that file without the use of /proc.
The actual fallacy of the "problem report" is the flawed assumption
about what a link count of 1 tells you.
The link count of a files tells you the number of hard links that
are persisted within the same filesystem. It is _NOT_ a promise
that there are no other means to access the inode of the file.
/proc creates a virtual reference to an inode, and since it is
virtual (and in a different filesystem) and not persisted in the
original filesystem, you will not see it in the link count of
the original filesystem.
There may be other (virtual) filesystems with similar features.
Some Linux distros with Live-CDs (such as Knoppix) use some sort
of Overlay filesystem (UNIONFS) which is also purely virtual,
none of the changes in the UNIONFS are persited into the
underlying filesystem. The inode is part of the administrative
data to manage the filesystem space&usage.
It is simply inappropriate for an application to draw invalid
conclusions from the link count of a files inode.
>
> > Therefor it's totally of no influence what you do with the original
> > directory permission. File access has nothing to do with directory
> > permissions...!
>
> Right. However the whole point of this discussion is that that is a
> non-obvious point, there was no other way that the user could have
> opened that file without the use of /proc.
The actual fallacy of the "problem report" is the flawed assumption
about what a link count of 1 tells you.
The link count of a files tells you the number of hard links that
are persisted within the same filesystem. It is _NOT_ a promise
that there are no other means to access the inode of the file.
/proc creates a virtual reference to an inode, and since it is
virtual (and in a different filesystem) and not persisted in the
original filesystem, you will not see it in the link count of
the original filesystem.
There may be other (virtual) filesystems with similar features.
Some Linux distros with Live-CDs (such as Knoppix) use some sort
of Overlay filesystem (UNIONFS) which is also purely virtual,
none of the changes in the UNIONFS are persited into the
underlying filesystem. The inode is part of the administrative
data to manage the filesystem space&usage.
It is simply inappropriate for an application to draw invalid
conclusions from the link count of a files inode.
-Martin
[ reply ]