Date: Sat, 17 Jun 2000 09:25:03 -0700 (PDT) From: bjh21@cam.ac.uk To: freebsd-gnats-submit@FreeBSD.org Subject: bin/19354: ls(1) handles odd characters in ssymbolic links badly Message-ID: <20000617162503.EA7B237B527@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 19354 >Category: bin >Synopsis: ls(1) handles odd characters in ssymbolic links badly >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 17 09:30:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Ben Harris >Release: 4.0-CURRENT >Organization: University of Cambridge >Environment: FreeBSD cookie.csi.cam.ac.uk 4.0-STABLE FreeBSD 4.0-STABLE #0: Mon Jun 12 14:53:09 BST 2000 root@cookie.csi.cam.ac.uk:/usr/src-new/src/sys/compile/4.0GENPLUS i386 >Description: From NetBSD PRs 10384 and 10385: If I create a symlink (on ffs) whose name contains a newline (ASCII LF) character, "ls -l" fails to display the contents of the link correctly, giving "No such file or directory". The message seems to indicate that ls is passing the filename to readlink() after replacing odd characters with question marks. Sending the output of ls through "cat" (to disable -q) works around the problem. When giving a long (-l) listing, ls(1) doesn't replace special characters in the targets of symlinks with question marks. This means that by inserting suitable escape sequences in the contents of symbolic links, one can do arbitrary awkward things to the display of someone running "ls -l" on a directory, and probably cause ls to appear not to list certain files. >How-To-Repeat: cromarty:/tmp$ ln -s "one line" "two > lines" cromarty:/tmp$ ls -l "two > lines" ls: two?lines: No such file or directory lrwxrwxr-x 1 bjh21 wheel 8 Jun 17 15:02 two?lines cromarty:/tmp$ ls -l "two > lines" | cat lrwxrwxr-x 1 bjh21 wheel 8 Jun 17 15:02 two lines -> one line $ ln -s `printf '\033c'` link $ ls -l Or, more fun: $ mkdir hidden $ ln -s `printf '\033[2K\033[F\033[2K\033[F'` hidden2 $ ls -l >Fix: See patches in NetBSD PR#10385. I suspect these are applicable to FreeBSD. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000617162503.EA7B237B527>