[bug #29809] creating a firmlink loop results in memory exhaustion

[Carl Fredrik Hammar]

Follow-up Comment #2, bug #29809 (project hurd):

Here is what happens with a settrans -ac foo; ls foo:

0 Client does a dir_lookup("foo") on CWD, presumably on ext2fs
0 ext2fs does a fsys_getroot() on firmlink
0 firmlink does a dir_lookup("foo") on (same) CWD
0 Back to (2)

The important bit is that control never goes back to the client, which
would've made glibc fail with ELOOP after a certain number of retries.
The core problem is related to a poor reaction to resource exhaustion,
but we might want to add loop detection to firmlink as a special case
if it can be done easily.

There is no way to the differentiate the first fsys_getroot() call from
the subsequent ones, so this can't be the base for loop detection.

So can we give the client back control so it can detect loops?  No,
because having access to any retry could lead to privilege escalation,
and any subsequent magical or reauth retry would also be interpreted in
the wrong context.  This really puts a nail in the coffin because firmlink
is itself a client to all the translators between it and the target.
So it seems it is impossible to detect arbitrary loops, at least, not
without changing the lookup protocol somehow.

However, tight loops can be detected by opening the target node with
O_NOLINK and check whether the result is the symlink-like port returned
by firmlink for such requests.  This would be easy enough, and I think
doing the check at startup would do the trick and cheap enough to be
worth it for even if it is limited to tight loops.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/