Re: [linux-security] Things NOT to put in root's crontab

[jenkins () DPW COM (Colin Jenkins)]

Philip Guenther writes:

> Watch your citing, I said that, not William McVey.

Sorry, got carried away trimming things.

I wrote:
> > One major problem with this approach is that it assumes that file names
> > are passed to -exec directives with the intent of operating on the file itself.
> > This ignores the fact that many -exec directives operate on the *file name*,
> > and it may be critical to pass a full pathname.  This requirement of passing
> > a full path name is in conflict with the algorithm's purpose.
>
> This is true.  Perhaps a "{}" on the command line should be sub'ed with
> the relative name and a "{{}}" should be sub'ed with the absolute
> name.

I agree that find's syntax would have to be (and should) be extended.
Unfortunately, without extending the syntax of find, I think it would be
virtually impossible to "fix" find to resolve this particular problem without
breaking other uses of find.

> > > open one descriptor for each level descended which should max out at
> > > MAXPATHLEN/2.  That should be within the bounds of modern UNIX systems.
> >
> > I think the limiting number here has less to do with path length, and more
> > to do with NOFILE, the maximum number of file descriptors a process can have
> > open.  On many systems, this is only 256 (except solaris at 1024 I believe).
>
> If MAXPATHLEN/2 < NOFILE then this shouldn't be a problem. Remember,
> this is _not_ following symlinks, so you can only chase MAXPATHLEN/2

True, but since most Unix systems have a MAXPATHLEN = 1024 and NOFILE = 256,
the condition MAXPATHLEN/2 < NOFILE is rarely met.  On top of that, you have
to subtract STDIN, STDOUT, and STDERR from the equation so you would really
need (MAXPATHLEN/2 - 3) < NOFILE.

> > I'd suggest that the best solution to the problem is a program written
> > specifically for the purpose of deleting or changing files.  Although I like
> > recursion in theory, the error recovery problems inherent in deep directory
> > nesting are more easily addressed with an iterative approach.
>
> I don't see how you can cover a tree with any efficiency without saving
> a hook (here, a file descriptor) to each level of directory as go in.

The problem with the recursive algrorith is that it is impossible to guarantee
that it will work all the time on all systems.  That is to say that anytime
(MAXPATHLEN/2 - 3) > NOFILE, this version of find can never descend to the
maximum number of nested directories that the operating system can support.
This in itself is a huge security hole as it would allow hackers to "hide"
things in places that could never be seen with a find command (which I use all
the time to "find" things!).  Even well meaning users sometimes create deep
directory nestings through errors in scripts and so on, so the issue carries
beyond security to mandatory maintenance requirements.  Two notable systems
that the algorithm will not work on are Linux and SunOS 4.x.

Even if you find a system where (MAXPATHLEN/2-3) < NOFILE, how can you be
certain that this equation will hold true from OS release to OS release?
My personal preference is to opt for portability and reliability- I want
the things I write (or use!) to work everywhere all the time.

As for having a hook for efficiency- you have one- just chdir("..") once
you have finished scanning a directory.  I will admit to a weakness in
this approach- if someone moves the directory you are currently scanning
to a different location before you chdir(".."), you could end up in the
wrong place.  To prevent this, you would need to keep a stack of paths
and check each return to ".." against the current value on the top of the
stack.  Here you could safely use recursion and avoid creating a stack.
All you'd have to do is perform a getwd() before making the recursive call,
and call it again after the return from recursion to make sure you ended up
back where you started.

> Philip Guenther                 UNIX Systems and Network Administrator


                                                    Colin
                                                    jenkins () dpw com