linux-kernel - Re: st_size of a symlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Jul 2012 21:22:24 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Jesper Juhl <jj@...osbits.net>
Cc:	Richard Weinberger <richard@....at>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org, linux-man@...r.kernel.org
Subject: Re: st_size of a symlink

On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:
> So, from my point of view it looks like procfs is the one who has got it 
> wrong.
> We should probably fix that (IMVHO).

Fix it _how_?  Try to rename a binary you have running in a process.
Or rename its cwd.  Or rename an opened file.  Watch the corresponding
procfs symlink (still pointing to the swame object) change.  With
no way to tell that some sucker had looked at st_size some time ago
and might get surprised by the change.

The fact is, st_size is just a useful hint for symlink target length.
It tells you the likely sufficient size of buffer.  There's a reason
why readlink(2) returns what it returns; you *can't* rely on the
earlier lstat() results or, for that matter, any prior information.
If nothing else, I could rm that symlink and create a new one in
the meanwhile.  You need to check what it had returned and deal with
insufficient buffer size.  By retrying readlink() with bigger buffer.
With procfs there's just a few more ways the readlink() output can
change, that's all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/