Bug #2030

fstatfs() fails in chroot environments

Added by ftigeot almost 4 years ago. Updated over 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

While investigation a ld-elf.so.2 error, I found out the following call returns
a non-zero value in a chroot:

fstatfs(fd, &fs)

the returned value is actually ENOENT, but the corresponding file exists

History

#1 Updated by alexh almost 4 years ago

On what file system does this happen?

Regards,
Alex

#2 Updated by ftigeot almost 4 years ago

On Mon, Mar 21, 2011 at 09:09:27PM +0000, Alex Hornung (via DragonFly issue tracker) wrote:
>
> Alex Hornung <> added the comment:
>
> On what file system does this happen?

Hammer. root / non-root does not really make any difference.

I have written a test program available here:
http://dl.zefyris.com/fstatfs.c

Cheers,

#3 Updated by swildner over 3 years ago

On 3/21/2011 9:49, Francois Tigeot (via DragonFly issue tracker) wrote:
>
> New submission from Francois Tigeot<>:
>
> While investigation a ld-elf.so.2 error, I found out the following call returns
> a non-zero value in a chroot:
>
> fstatfs(fd,&fs)
>
> the returned value is actually ENOENT, but the corresponding file exists

I followed the path a bit and it fails in cache_fullpath() in
sys/kern/vfs_cache.c in line #3281 in the "if (ncp == NULL)" check.

Sascha

#4 Updated by dillon over 3 years ago

fixed in 92734e3dc3576d68a28eb7d539dd48de730ab82d. fstat[v]fs() was using the
wrong mount pointer when calling cache_fullpath().

Also note that the test program supplied is buggy, this line is broken and
causes the fd to be assigned the value 0:

if (fd = open(FILE_PATH, O_RDONLY) == -1) ... should be
if ((fd = open(FILE_PATH, O_RDONLY)) == -1) ...

-Matt

Also available in: Atom PDF