[cifs] semantics of IPC$ shares (was Re: [PATCH] devpts: Fix NULL pointer dereference in dcache_readdir())

[cifs] semantics of IPC$ shares (was Re: [PATCH] devpts: Fix NULL pointer dereference in dcache_readdir())

[Al Viro]

On Fri, Oct 04, 2019 at 05:02:20PM +0100, Al Viro wrote:

> 	* (possibly) cifs hitting the same on eviction by memory pressure alone
> (no locked inodes anywhere in sight).  Possibly == if cifs IPC$ share happens to
> show up non-empty (e.g. due to server playing silly buggers).
> 	* (possibly) cifs hitting *another* lovely issue - lookup in one subdirectory
> of IPC$ root finding an alias for another subdirectory of said root, triggering
> d_move() of dentry of the latter.  IF the name happens to be long enough to be
> externally allocated and if dcache_readdir() on root is currently copying it to
> userland, Bad Things(tm) will happen.  That one almost certainly depends upon the
> server playing silly buggers and might or might not be possible.  I'm not familiar
> enough with CIFS to tell.

BTW, I would really appreciate somebody familiar with CIFS giving a braindump on
that.  Questions:

1) What's normally (== without malicious/broken server) seen when you mount
an IPC$ share?

2) Does it ever have subdirectories (i.e. can we fail a lookup in its root if it
looks like returning a subdirectory)?

3) If it can be non-empty, is there way to ask the server about its contents?
Short of "look every possible name up", that is...

As it is, the thing is abusing either cifs_lookup() (if it really shouldn't
have any files in it) or dcache_readdir().  Sure, dcache_readdir() can (and
should) pin a dentry while copying the name to userland, but WTF kind of
semantics it is?  "ls will return the things you'd guessed to look up, until
there's enough memory pressure to have them forgotten, which can happen at
any point with no activity on server"?

Re: [cifs] semantics of IPC$ shares (was Re: [PATCH] devpts: Fix NULL pointer dereference in dcache_readdir())

[Steve French]

Your questions are interesting and rarely asked.

On Fri, Oct 4, 2019 at 11:57 AM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Fri, Oct 04, 2019 at 05:02:20PM +0100, Al Viro wrote:
>
> >       * (possibly) cifs hitting the same on eviction by memory pressure alone
> > (no locked inodes anywhere in sight).  Possibly == if cifs IPC$ share happens to
> > show up non-empty (e.g. due to server playing silly buggers).
> >       * (possibly) cifs hitting *another* lovely issue - lookup in one subdirectory
> > of IPC$ root finding an alias for another subdirectory of said root, triggering
> > d_move() of dentry of the latter.  IF the name happens to be long enough to be
> > externally allocated and if dcache_readdir() on root is currently copying it to
> > userland, Bad Things(tm) will happen.  That one almost certainly depends upon the
> > server playing silly buggers and might or might not be possible.  I'm not familiar
> > enough with CIFS to tell.
>
> BTW, I would really appreciate somebody familiar with CIFS giving a braindump on
> that.  Questions:
>
> 1) What's normally (== without malicious/broken server) seen when you mount
> an IPC$ share?

IPC$ is for "inter process communication" so is basically an
abstraction for named pipes (used
for remote procedure call queries using the old DCE/RPC standard).

To Windows it is possible to mount IPC$, to Samba you can connect to
the share but
due to a Samba server bug you can't do a query info on "." (the 'root'
of the IPC$ share).


> 2) Does it ever have subdirectories (i.e. can we fail a lookup in its root if it
> looks like returning a subdirectory)?

In Samba you can't query subdirectories on IPC$ because even open of "."
fails, but to Windows the query directory would get "STATUS_INVALID_INFO_CLASS"

An interesting question, and one that I will bring up with the spec
writers is whether
there are info level which would be allowed for query directory (probably not).

Another interesting question this brings up is ... "should we allow
enumerating the 'services' under IPC$
via readdir"?   You could imagine a case where mounting IPC$ would
allow you to see the 'services'
exported by the server over remote procedure call ("server service"
and "workstation server" and "netlogon service"
and the global name space (DFS) service and  perhaps "witness protocol
services" and "branch cache service" etc.)

And then thinking about Dave Howell's changes to the mount API -
should this be a mechanism that is allowed to be
used to either browse the valid shares or better access the root of
the (DFS) global name space.

But the short answer is "no you can't query the directory contents
under IPC$" (at least not without changing the
abstraction that we export on the client) but I am open to ideas if
this would fit with Dave Howell's changes to the
mount API or other ideas.
> 3) If it can be non-empty, is there way to ask the server about its contents?
> Short of "look every possible name up", that is...
>
> As it is, the thing is abusing either cifs_lookup() (if it really shouldn't
> have any files in it) or dcache_readdir().  Sure, dcache_readdir() can (and
> should) pin a dentry while copying the name to userland, but WTF kind of
> semantics it is?  "ls will return the things you'd guessed to look up, until
> there's enough memory pressure to have them forgotten, which can happen at
> any point with no activity on server"?

Server's realistically must expose a share "IPC$" so in theory it can be mounted
(despite Samba server's current bug there) and there were some experiments
that Shirish did a few years ago opening well known services under mounts
to IPC$ (to allow doing remote procedure calls over SMB3 mounts which has
some value) but AFAIK you would never do a readdir over IPC$ and no
current users would ever mount IPC$

-- 
Thanks,

Steve