lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <959b0495a90e45b9816bb9f25d76a8f9@AcuMS.aculab.com>
Date:   Wed, 1 Jun 2022 15:40:31 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Kalesh Singh' <kaleshsingh@...gle.com>,
        Stephen Brennan <stephen.s.brennan@...cle.com>
CC:     Ioannis Ilkos <ilkos@...gle.com>,
        "T.J. Mercier" <tjmercier@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Jonathan Corbet <corbet@....net>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Christian König <christian.koenig@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "David Hildenbrand" <david@...hat.com>,
        Christoph Anton Mitterer <mail@...istoph.anton.mitterer.name>,
        Johannes Weiner <hannes@...xchg.org>,
        Colin Cross <ccross@...gle.com>,
        Mike Rapoport <rppt@...nel.org>,
        "Paul Gortmaker" <paul.gortmaker@...driver.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        DRI mailing list <dri-devel@...ts.freedesktop.org>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>
Subject: RE: [PATCH 2/2] procfs: Add 'path' to /proc/<pid>/fdinfo/

From: Kalesh Singh
> Sent: 31 May 2022 23:30
...
> > File paths can contain fun characters like newlines or colons, which
> > could make parsing out filenames in this text file... fun. How would your
> > userspace parsing logic handle "/home/stephen/filename\nsize:\t4096"? The
> > readlink(2) API makes that easy already.
> 
> I think since we have escaped the "\n" (seq_file_path(m, file, "\n")),
> then user space might parse this line like:
> 
> if (strncmp(line, "path:\t", 6) == 0)
>         char* path = line + 6;

The real annoyance is other things doing scans of the filesystem
that accidentally 'bump into' strange names.

While anything serious probably gets it right how many times
Do you run 'find' to quickly search for something?

Spaces in filenames (popularised by some other os) are a PITA.
Not to mention leading and trailing spaces!
Anyone using filenames that only contain spaces does need shooting.

Deliberately adding non-printables isn't really a good idea.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ