Bug#149722: libc6: ldd: bogus check for read permission

[Pierre HABOUZIT]

# ctl is in bcc
reassign 149722 bash
thanks

On Tue, Jun 11, 2002 at 09:50:55PM -0400, Aaron M. Ucko wrote:
 Package: libc6
 Version: 2.2.5-6
 Severity: minor
 File: /usr/bin/ldd
 
 ldd insists on bailing out if its argument fails test -r, which in
 turn may not always yield a terribly meaningful value on file systems
 whose semantics are not completely Unix-like.  (In particular, AFS
 ignores the group and other bits when checking permissions -- so I may
 still be able to read a mode 700 file owned by somebody else if I'm on
 the right ACL.)  Perhaps this is really a bug in test (i.e., bash),
 but I don't see any good reason for ldd to be checking access in the
 first place.

  /usr/bin/test -r basically performs:

  access(..., R_OK)

  so the problem is definitely not in the libc, but rather in AFS _or_
in bash.

  further search proves that I'm right: bash test builtin implements
access its own way (wtf?!) rather than using access. bash has to be
complied with -DAFS to use access(2), which it's obviously not under
debian:

$ cat a.sh
#! /bin/bash

test -r /etc/passwd
$ strace bash a.sh 21 | grep passwd
stat(/etc/passwd, {st_mode=S_IFREG|0644, st_size=1710, ...}) = 0


  reassigning.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpCWJuyyyGbf.pgp
Description: PGP signature

Bug#149722: libc6: ldd: bogus check for read permission

[Aaron M. Ucko]

Pierre HABOUZIT [EMAIL PROTECTED] writes:

 # ctl is in bcc
 reassign 149722 bash

Fair enough (building bash with -DAFS is probably a good idea in any
case), but I'd still appreciate a response to the last line or so of
my original report:

 but I don't see any good reason for ldd to be checking access in the
 first place.

To wit, why should ldd *care* whether its argument appears to be
readable (or, for that matter, executable, though failing that check
merely leads to a warning) at all?  Security vaguely comes to mind,
but the restriction's too easy to circumvent in normal circumstances
for that to carry much weight.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#149722: libc6: ldd: bogus check for read permission

[Pierre Habouzit]

On Tue, Feb 06, 2007 at 08:04:33PM -0500, Aaron M. Ucko wrote:
 Pierre HABOUZIT [EMAIL PROTECTED] writes:
 
  # ctl is in bcc
  reassign 149722 bash
 
 Fair enough (building bash with -DAFS is probably a good idea in any
 case), but I'd still appreciate a response to the last line or so of
 my original report:
 
  but I don't see any good reason for ldd to be checking access in the
  first place.
 
 To wit, why should ldd *care* whether its argument appears to be
 readable (or, for that matter, executable, though failing that check
 merely leads to a warning) at all?  Security vaguely comes to mind,
 but the restriction's too easy to circumvent in normal circumstances
 for that to carry much weight.

  well, /usr/bin/ldd is just a bash script quite easy to read. IMHO the
sole reason test -r is performed is to give readable error messages to
the user. the script is a matter of:

if test -r $file; then
if ! test -x $file  file is not a library; then
# barf about it not beeing executable by you
fi
# do our stuff
else
# readable error message
fi


eventually, ldd runs sth that looks like:

  LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION= 
LD_VERBOSE= /lib/ld-2.3.6.so $file

if $file do not exists e.g. it gives:

  /bin/bas: error while loading shared libraries: /bin/bas: cannot open shared 
object file: No such file or directory

With ldd, you have a nice _localized_ user readable error message.
ldd /bin/bas
ldd: /bin/bas: No such file or directory

Here is the why and how :)

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvSXteTQGc2.pgp
Description: PGP signature