bin/38987: find(1) doc glitches for -delete

[kre%munnari.OZ.AU@localhost]

>Number:         38987
>Category:       bin
>Synopsis:       find(1) doc glitches for -delete
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 19 13:40:00 +0000 2008
>Originator:     Robert Elz
>Release:        NetBSD 4.99.62
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD epsilon.noi.kre.to 4.99.62 NetBSD 4.99.62 (EPSILON-1.2-20080507) 
#3: Sat May 10 16:45:19 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/current/kernels/EPSILON i386
Architecture: i386
Machine: i386
>Description:
        In the description of the -delete option, find(1) says
        (amongst other things)

           It will not attempt to delete a filename with a
           ``'' character in its pathname relative to ``''.  for security
           reasons.

        This has 3 separate problems.

        1. (I hope) is trivial to someone who understands how to manipulate
           mdoc.  By inspection of find.1 (man page source code) it is
           clear that what it intends to say is ...

             It will not attempt to delete a filename with a
             ``/'' character in its pathname relative to ``.'' for security
             reasons.

           The formatting error is caused by the "intelligence" of mdoc,
           and its attempt to allow
                .Dq hello world
           to produce
                        ``hello world''
           whereas
                .Dq hello .
           is to produce
                        ``hello''.

           That's kind of smart, I guess, but mdoc should probably be
           modified so if it is handed only a single arg, containing just
           a punctuation character, it quotes the character, rather than
           quoting nothing and following it by the punctuation character.
           In the unlikely event that nothing followed by punctuation is
           what is really desided, the invocation
                .Dq \& .
           would still permit that.

           This is clearly what turned what should have been
                ``.''
           into
                ``''.
           On the other hand, where the '/' vanished to in the earlier
           use of .Dq I have no idea.  '/' does not appear to be one of
           mdoc's magic punctuation characters.

           Whoever modified find(1) to add this seems to have decided that
           \ quoting the . and / would make some kind of difference, but
           I cannot imagine what gave that impression (except perhaps the
           homily "if it is troff and doesn't work, try inserting a '\'".)

        2. Once that gets fixed, we now have a sentence that I (at least)
           cannot translate into anything I understand.   That is, I have no
           understanding at all of what a
                "/ character in a pathname relative to ."
           is intended to mean.  My guess is that it might mean "./" or "/."
           or ???   Whatever it is, this needs to be stated more clearly,
           and not in some kind of shorthand.

        3. The final three words above "for security reasons" is clearly
           nonsense.  Find is just a regular user program, anything find
           could ever do, I can just as easily do by writing a simple C
           program and calling unlink(2) or rmdir(2) with whatever pathname
           it is that find is refusing to act upon.   So, there cannot
           possibly be any security reasons for this.

           It may be "to avoid the effects of common incorrect usage" or
           something (ie: people don't realise what it means, or what effect
           it might have, and inadvertantly do something they didn't intend).
           That's not a security reason (though it might be a valid reason
           for the restriction in find).

           Or, it may be, that someone is imagining that scripts run by
           root will do nasty things when root uses -delete and doesn't
           bother adding the necessary find args to validate the path first.
           That's also not a security reason, that's making life simpler for
           idiot administrators (if a security fix was needed for something
           there it would be to correctly invoke find safely.)

>How-To-Repeat:
        Simple answer: RTFM

        More long winded - be reading the NetBSD lists from Feb 2007
        (that's where I'm up to in my perusal of the lists in general)
        and notice the discussion about adding -rm as an alias for -delete,
        and a comment that -delete doesn't do what would be expeced of -rm,
        become mildly curious, and decide to read the man page to find out
        what it is all about (the find commands I used in the past had none
        of this stuff in them...)    Read it and weep.

>Fix:
        For (1) - invoke wizd
                Short of fixing mdoc, I'd use .Dq \&. and .Dq \&/ so that
                the arg doesn't appear to be a punct char, but prints just
                like as if it were.
        For (2) - have someone who knows what pathnames find will actually
                refuse to remove actually write some text that says what
                they are.
        For (3) - just remove the words "for security reasons."
                Replace them with a more plausible explanation if desired,
                but it is really not necessary.