Bug 3353

Summary:	ttyname's new strict dependency on /proc breaks chrooted applications
Product:	glibc	Reporter:	Jitendra Nair <jnair>
Component:	libc	Assignee:	Ulrich Drepper <drepper.fsp>
Status:	RESOLVED DUPLICATE
Severity:	critical	CC:	fweimer, glibc-bugs, shekhar.tiwatne
Priority:	P1	Flags:	fweimer: security-
Version:	2.4
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:

Description Jitendra Nair 2006-10-12 11:38:26 UTC

I am a FC6(test3) user. glibc version comes with the distro is 2.4.90-29.
My application runs sshd daemon and logons users to their respective chrooted
homes. Now /proc is not purposely made available in the chrooted env. 
sshd's login process (chrooted) calls ttyname. It fails as it does not find
/proc mounted. This used to work with glibc-2.4-4 (on FC5) and before.
Now this strict dependency breaks my application. Even simple command like `tty`
fails in if /proc is not mounted.

Comment 1 Ulrich Drepper 2006-10-12 20:57:07 UTC

glibc cannot work reliably at all without /proc.  This is (unfortunately) the
only interface to all kinds of kernel details.

Comment 2 Jakub Jelinek 2006-10-12 21:04:20 UTC

BTW, if you for whatever reason don't want to mount whole /proc into the chroots,
you can always at least mount --bind there parts of it sufficient enough
to make all programs you want to run in the chroot happy.

Comment 3 Jitendra Nair 2006-10-13 05:30:31 UTC

(In reply to comment #2)
> BTW, if you for whatever reason don't want to mount whole /proc into the chroots,
> you can always at least mount --bind there parts of it sufficient enough
> to make all programs you want to run in the chroot happy.


I agree but, 'ttyname' i belive does a 'readlink'  on '/proc/self/fd/n' and
'self' will be known only to the forked 'sshd' child,so binding 'part' of the
proc fs in this case is not possible. Hope i got it right.

Comment 4 Florian Weimer 2014-06-17 04:51:07 UTC

Fixed.

*** This bug has been marked as a duplicate of bug 1451 ***

Comment 5 Florian Weimer 2014-06-17 13:39:21 UTC


*** This bug has been marked as a duplicate of bug 14516 ***