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:	Tue, 24 Jul 2012 00:07:48 +0200
From:	Richard Weinberger <richard@....at>
To:	Jesper Juhl <jj@...osbits.net>
CC:	Al Viro <viro@...IV.linux.org.uk>,
	"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 23.07.2012 22:47, Jesper Juhl wrote:
>> Fix it _how_?
>
> By returning the size as the number of bytes in the name the link is
> currently pointing at.

This is not easy.
procfs has no clue where the link pointing at.
The information is generated while accessing the link.
tmpfs on the other hand has this information because symlinks get only 
changed through tmpfs...

>>   By retrying readlink() with bigger buffer.
>> With procfs there's just a few more ways the readlink() output can
>> change, that's all.
>>
> Still not a good reason to just return 0 IMHO.

IMHO the lstat() and readlink() manpages have to be more precise about 
st_size.

Thanks,
//richard
--
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/