[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ext4
Subject:    [Ext2-devel] More symlink cleanups
From:       Andreas Dilger <adilger () turbolinux ! com>
Date:       2001-07-27 7:10:31
[Download RAW message or body]

I'm looking at further symlink checks in e2fsck as a result of the problems
people have experienced as a result of the immutable symlinks (for which I've
already sent a patch to Ted).

Other failure condiditions we are not currently handling properly:

1) zero-length symlinks: the kernel interprets this as a symlink to /,
   which is why the "chattr -i <bad link>" in the "immutable symlink"
   problem wasn't failing with "no such file or directory".  Definitely
   a bad inode, and I've fixed this already in my code.

2) symlinks > blocksize: on trying to create such a symlink the kernel
   fails in the ext2 code with -ENAMETOOLONG.  Concievably, we could have
   symlinks up to PAGE_SIZE, PAGE_CACHE_SIZE or possibly even longer with
   some effort, but up to now this has not been true.  Should e2fsck check
   for this and declare this a bad inode?  It would impose a limit where
   none (other than implementation) currently exists.  Alternately, we could
   set an arbitrary maximum symlink length.  Given that we have a maximum
   filename length of 255 characters, there is no real reason we would need a
   symlink length longer than, say, NDIR*blocksize, or 16384 characters.
   If this isn't enough for some absurd system you can always use multiple
   symlinks a -> b -> c.  I have this coded, but not sure if I should.

3) i_size != strlen(symlink): the ext2 kernel code currently always NUL
   terminates symlinks, and only creates symlinks of <max size>-1 chars
   (59 chars for fast symlinks, blocksize-1 for block symlinks).  The
   kernel ext2 and reiserfs code does "strlen(name)" in several places
   when creating the symlink, so it is virtually impossible for a symlink
   to contain NUL bytes.  Should we fix the symlink length to match the
   strlen?  Should we enforce that the string is NUL terminated and/or
   refuse symlinks at the maximum size of the symlink type?  I assume that
   since the data written to disk is always supposed to be NUL terminated,
   we _should_ trust the strlen() over i_size, unless it is the maximum
   possible length in which case we either mark it bad.  Haven't coded
   this, but it shouldn't be _too_ hard to do.

Cheers, Andreas
-- 
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

_______________________________________________
Ext2-devel mailing list
Ext2-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/ext2-devel

[prev in list] [next in list] [prev in thread] [next in thread]