Re: [PATCH v2] erofs: fix incorrect symlink detection in fast symlink

["Colin Walters" <walters@verbum.org>]

On Mon, Sep 9, 2024, at 11:40 AM, Gao Xiang wrote:
> 
> Just my personal opinion, my understanding of rubustness
> is stability and security.
>
> But whether to check or not check this, it doesn't crash
> the kernel or deadlock or livelock, so IMHO, it's already
> rubustness.

OK, if you're telling me this is already checked elsewhere then I think we can call this end of thread.

> Actually, I think EROFS for i_size > PAGE_SIZE, it's an
> undefined or reserved behavior for now (just like CPU
> reserved bits or don't care bits), just Linux
> implementation treats it with PAGE_SIZE-1 trailing '\0',
> but using erofs dump tool you could still dump large
> symlinks.
>
> Since PATH_MAX is a system-defined constant too, currently
> Linux PATH_MAX is 4096, but how about other OSes? I've
> seen some `PATH_MAX 8192` reference but I'm not sure which
> OS uses this setting.

Famously GNU Hurd tried to avoid having a PATH_MAX at all:
https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html

But I am pretty confident in saying that Linux isn't going to try to or really be able to meaningfully change its PATH_MAX in the forseeable future.

Now we're firmly off into the weeds but since it's kind of an interesting debate: Honestly: who would *want* to ever interact with such long file paths? And I think a much better evolutionary direction is already in flight - operate in terms of directory fds with openat() etc. While it'd be logistically complicated one could imagine a variant of a Unix filesystem which hard required using openat() to access sub-domains where the paths in that sub-domain are limited to the existing PATH_MAX. I guess that kind of already exists in subvolumes/snapshots, and we're effectively enabling this with composefs too.

> But I think it's a filesystem on-disk limitation, but if
> i_size exceeds that, we return -EOPNOTSUPP or -EFSCORRUPTED?
> For this symlink case, I tend to return -EFSCORRUPTED but
> for other similar but complex cases, it could be hard to
> decide.

-EFSCORRUPTED is what XFS does at least (in xfs_inactive_symlink()).