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 20:09:14 +0200 (CEST)
From:	Jesper Juhl <jj@...osbits.net>
To:	Richard Weinberger <richard@....at>
cc:	"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, 23 Jul 2012, Richard Weinberger wrote:

> Hi!
> 
> lstat(2) on /proc/$pid/exe gives me a stat object where st_size is 0.
> 
> Or:
> rw@...tary:~> ls -l /proc/$$/exe
> lrwxrwxrwx 1 rw users 0 23. Jul 17:02 /proc/16902/exe -> /bin/bash
> 
> The lstat(2) manpage says:
> "The st_size field gives the size of the file (if it is a regular file or a
> symbolic link) in bytes.  The size of a symbolic link is the length of the
> pathname it contains, without a terminating null byte."
> 
> This property is also used in the example in the readlink(2) manpage.
> 
> Is this a procfs issue or is the manpage wrong?
> 
I have relied on that behaviour (size of symlink being lengh of pathname 
it contains) in the past, so I know it used to work and I'd expect it to 
keep working.
I honestly never really thought about procfs, but checking now, it does 
seem that procfs doesn't quite do things right...

Just so we all know what kernel I'm running:
  [root@...h tmp]# uname -a
  Linux arch 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux

Let's see what procfs reports:
  [root@...h ~]# ls -l /proc/$$/exe
  lrwxrwxrwx 1 root root 0 Jul 23 19:58 /proc/884/exe -> /bin/bash
Doesn't seem quite right....

Now let's see what tmpfs reports:
  [root@...h tmp]# mount | grep /tmp
  tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
  [root@...h ~]# cd /tmp
  [root@...h tmp]# ln -s /tmp foo
  [root@...h tmp]# ls -l foo
  lrwxrwxrwx 1 root root 4 Jul 23 19:59 foo -> /tmp
Seems OK.

Let's check ext4:
  [root@...h tmp]# mount | grep /home
  /dev/sda4 on /home type ext4 (rw,relatime,data=ordered)
  [root@...h tmp]# cd /home/jj
  [root@...h jj]# touch foo
  [root@...h jj]# ln -s foo bar
  [root@...h jj]# ls -l bar
  lrwxrwxrwx 1 root root 3 Jul 23 20:03 bar -> foo
Seems OK as well..

So how about devtmpfs?
  [root@...h jj]# mount | grep devtmpfs
  dev on /dev type devtmpfs (rw,nosuid,relatime,size=779400k,nr_inodes=194850,mode=755)
  [root@...h jj]# ls -l /dev/stderr 
  lrwxrwxrwx 1 root root 15 Jul 23 19:46 /dev/stderr -> /proc/self/fd/2
Also looks OK...

So, from my point of view it looks like procfs is the one who has got it 
wrong.
We should probably fix that (IMVHO).


-- 
Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
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/