From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1167 invoked by alias); 28 Oct 2010 12:49:38 -0000 Received: (qmail 1157 invoked by uid 22791); 28 Oct 2010 12:49:36 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Oct 2010 12:49:31 +0000 From: "miklos at szeredi dot hu" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/12167] New: ttyname() and ttyname_r() may return wrong value X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: miklos at szeredi dot hu X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 28 Oct 2010 12:49:00 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00175.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=12167 Summary: ttyname() and ttyname_r() may return wrong value Product: glibc Version: 2.13 Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: miklos@szeredi.hu On linux 2.6.36: # mount --bind / /mnt/tmp # mount -t proc proc /mnt/tmp/proc # chroot /mnt/tmp # tty (unreachable)/dev/tty2 This is caused by commit 8df9d1a4 (vfs: show unreachable paths in getcwd and proc) explicitly marking files that are unreachable from the current root. Before this commit the symlink was either junk or contained the path from the namespace root which may, or may not point to the inode behind the file descriptor. Note: *following* the symlink (not reading it) always yielded the correct file. In addition these symlinks may contain the string "(deleted)" at the end if the file was unlinked after it was opened. The conclusion is that ttyname() should verify that the path returned from reading the symlink does indeed refer to the same device as the file descriptor. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.