Re: [9fans] truly hidden files!

Re: [9fans] truly hidden files!

[cinap_lenrek]

the point is that *YOU* control where to bind stuff in your
own namespaces. if you do not trust that directory, then
do not bind it over /dev or /bin or any part where programs
expect some sanity. the fact that you see or not see the files
does not matter. say you take someones contrib directory and
bind it before /bin. then the people controlling that directory
can make files appear and disappear and replace your /bin/rc.

you also need to trust the hostowner of the machines you
do your computation on.

--
cinap

[9fans] truly hidden files!

[Giacomo Tesio]

I don't know... but it must be something important! :-)

Btw, /dev/null is just an example: the strange thing is that a file
that does not appear in a 'cat folder/' can be opened in place of a
file that is visible there.
When you list a union you can see several files with the same name, so
you know what you are going to open. But here you can open a file that
is not actually visible in the containing folder.


Giacomo

2017-11-02 17:39 GMT+01:00  <cinap_lenrek at felloff.net>:
> what do you not understand about private namespaces?
>
> --
> cinap
>

Re: [9fans] truly hidden files!

[cinap_lenrek]

what do you not understand about private namespaces?

--
cinap

[9fans] truly hidden files!

[Giacomo Tesio]

Hi, while debugging a 9P2000 file server I realized that it's very
easy to hide file or folders in Plan 9: just don't include them in the
Rreads of the parent directory.

Given the protocol, I know I'm stating the obvious, but the effect
still surprises me.

Such files/folder would be accessible to programs knowing their exact
names but not visible to the poor user who ignore them.


I wonder if this can be turned to a security issue.
Eg an invisible pipe named "null" and bound before to /dev could
receive top secret data you wanted to destroy.


Giacomo
PS: knowing a program that use these hidden files, /proc/n/fd would
still reveal their path, but the path could still appear legitimate
like the case of /dev/null.