find crashed when current working directory is not readable and -exec or -execdir used

Bug #1347788 reported by Alexander Kudrevatykh on 2014-07-23
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
findutils (Ubuntu)
Low
Unassigned
Xenial
Low
Unassigned

Bug Description

bug is similar to https://savannah.gnu.org/bugs/?15384 but for current directory (when it not readable or not executable)

steps to reproduce

DIR=`mktemp -d`
cd $DIR
mkdir -p 1/1 2
chmod a-rw 2
cd 2
find $DIR/1 -type d -exec echo {} \;
find $DIR/1 -type d -execdir echo {} \;

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: findutils 4.4.2-7
Uname: Linux 3.15.4-031504-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Date: Wed Jul 23 20:17:19 2014
Dependencies:
 gcc-4.9-base 4.9-20140406-0ubuntu1
 libc6 2.19-0ubuntu6
 libgcc1 1:4.9-20140406-0ubuntu1
 multiarch-support 2.19-0ubuntu6
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
SourcePackage: findutils
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: GNOME
Dependencies:
 gcc-4.9-base 4.9-20140406-0ubuntu1
 libc6 2.19-0ubuntu6
 libgcc1 1:4.9-20140406-0ubuntu1
 multiarch-support 2.19-0ubuntu6
DistroRelease: Ubuntu 14.04
InstallationDate: Installed on 2014-04-24 (89 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
Package: findutils 4.4.2-7
PackageArchitecture: amd64
Tags: trusty
Uname: Linux 3.15.4-031504-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

tags: added: apport-collected
description: updated

apport information

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in findutils (Ubuntu):
status: New → Confirmed
Philip Blakely (pmblakely) wrote :

I just marked this as affecting me as well. However, I had to add one other step to reproduce the bug using the instructions above. As the bug title says, the problem only happens when the working directory (not necessarily the one on which find is being run) is unreadable or not executable by the current user. So, I had to add "chmod u-r ./2" before the line "cd 2". The find command then fails with

find: pred.c:1932: launch: Assertion `starting_desc >= 0' failed.
Aborted (core dumped)

As a real-world example of this bug, this can happen when you are logged-in as root, and in /root and "su" to another user. You are therefore left in /root but without having read/execute permissions to it. find with -exec therefore fails, even if you are searching another directory. This came up while using Puppet, which included a 'find' command. Of course, switching to another directory solved the problem.

Eric Desrochers (slashd) wrote :

Upstream bug:
---
bug #44078: Find fails if executed from a directory on which the user has no list permissions and exec is an option used[1]
---

Fix:
---
commit 7dc70069a3095a42eadb22b24cb9260c243aff8f
Author: James Youngman <email address hidden>
Date: Sat Apr 10 17:15:01 2010 +0100

Exec predicates now store which directory they want to run in
---

[1] http://savannah.gnu.org/bugs/?44078
[2] http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=34deb851d8

Dave Chiluk (chiluk) on 2015-11-12
Changed in findutils (Ubuntu):
assignee: nobody → Dave Chiluk (chiluk)
Dave Chiluk (chiluk) on 2015-11-12
Changed in findutils (Ubuntu):
importance: Undecided → Low
Dave Chiluk (chiluk) wrote :

I opened
https://savannah.gnu.org/bugs/index.php?46438
against upstream findutils to see if we can't get them to to a blessed release of 4.5 of findutils.

Dave Chiluk (chiluk) wrote :

I also reviewed the upstream patch that purports to resolve the issue (7dc7006). This fix is contained within the 4.5.9 and newer versions of findutils. That's where the good news ends. The code portion of that single commit is 817 lines long. It doesn't apply cleanly, and it appears to have some significant dependencies on earlier commits.

Unfortunately backportting the fix into even wily sources is proving difficult, and may not be acceptable for a stable release. Normally in this case we would integrate the entire upstream sources into our development series (xenial), and then pursue package copy into the older series. However, 4.5.9 and newer is currently part of the findutils alpha branch, and as such wouldn't be considered acceptable for inclusion in even our development releases.

That being said fedora, opensuse, and centos all release with 4.5 of findutils, so we may have to consider doing the same.

Dave Chiluk (chiluk) on 2015-12-07
Changed in findutils (Ubuntu Xenial):
assignee: Dave Chiluk (chiluk) → nobody
Dave Chiluk (chiluk) wrote :

Talked to Pitti during the last foundations meeting. He mentioned possibly doing a merge of findutils 4.5.14-3 from debian-experitmental to xenial. That should contain fix required to resolve this bug.

Changed in findutils (Ubuntu Xenial):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

FTR, the sync of the Debian experimental package was pulled because it fails on ppc64el. So this needs a cherry-picked fix instead.

Changed in findutils (Ubuntu Xenial):
assignee: Martin Pitt (pitti) → nobody
Dave Chiluk (chiluk) wrote :

Well that's supremely disappointing. I'll see what I can do.

Dave Chiluk (chiluk) wrote :

Findutils just released a new blessed stable version 4.6.0

http://savannah.gnu.org/bugs/?46438

What are the chances of getting this included into xenial?

Dave Chiluk (chiluk) wrote on 2016-01-07: #11
> Findutils just released a new blessed stable version 4.6.0
[...]
> What are the chances of getting this included into xenial?

Xenial is now at > 4.6. (4.6.0+git+20160126-2 )

Dave Chiluk (chiluk) on 2016-02-24
description: updated
Changed in findutils (Ubuntu Xenial):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.