"""FUN""" fact!!!
/ is crap! did you know that when you have a symlink on the host to, mmm, let's say, the root directory, then the client will not see that as a symlink but as if it was a fucking bind mount??????



was right, symlinks are bad

Β· Β· brutaldon Β· 4 Β· 6 Β· 7

update on the gvfs thing, I don't think it's sftp since the docs for that seems to suggest that it _can_ distinguish between symlinks and files, so the culprit is probably the gvfs wrapper for sftp


I think that's an sftp issue (probably ftp would be affected too): there is no symlink in ftp protocol, so the server does not care.

To be fair, a bind of / in a folder servee by a ftp server would have the same issue on Plan9 too.

Bind try to make the fs a tree but doesn't prevent loop (at least in the default implementation).

@Shamar yeah, Plan 9 has fewer safeguards too, but at least all the trickery is more or less in one place there

also binds have a limited lifetime, so you don't run into something like this, where a directory you never looked into has some weird symlinks that you didn't expect

@grainloom good point.

Namespace are per process group so whatever you bind in a shell are unlikely to be visible from a ftp server (unlikely though)

@Shamar it's also localized to bind and mount and you can see the whole namespace with ns
on Linux you have... symlink... hardlink.. mount.. bind mount... overlayfs... gvfs... maybe others I don't know about
and the fun part is, gvfs is a single mount entry, it serves its own file system on /run/user/$UID/gvfs, so even if you run rm(1) with --one-file-system, it probably won't detect file system boundaries

(course you can make the same mistake in Plan 9 but Plan 9 doesn't need a GVFS)

@ckeen I kinda hope it's only the fault of one of those things....

Sign in to participate in the conversation

the mastodon instance at cybre.space is retiring

see the end-of-life plan for details: https://cybre.space/~chr/cybre-space-eol