bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

rmdir --ignore-fail-on-non-empty fails with permission denied


From: Bob Proulx
Subject: rmdir --ignore-fail-on-non-empty fails with permission denied
Date: Tue, 29 Jan 2008 10:58:29 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

Please maintain the CC to both the bug number and the mailing list
when responding.  Thanks.

Reported to the Debian BTS:

  http://bugs.debian.org/350541

'rmdir --ignore-fail-on-non-empty' will ignore non-empty directories
unless it has insufficient permission to remove them, in which case it
fails.  Can rmdir avoid failing in this case?

Here is a way to reproduce the issue.  Root access is required in
order to have permission to set the immutable attribute.  The
filesystem needs to be ext2-like in order to support it.

  # mkdir testdir
  # mkdir testdir/foo
  # mkdir testdir/foo/bar
  # mkdir testdir/foo/boo
  # chattr +i testdir
  # rmdir -p --ignore-fail-on-non-empty testdir/foo/bar ; echo $?
  rmdir: testdir/foo: Permission denied
  1

But without the immutable attribute:

  # chattr -i testdir
  # mkdir testdir/foo/bar
  # rmdir -p --ignore-fail-on-non-empty testdir/foo/bar ; echo $?
  0

This was found in a package postrm script which tried to clean up by
doing the following:

  rm -f /etc/gconf/2/path
  rmdir -p --ignore-fail-on-non-empty /etc/gconf/2
  rmdir: `/etc': Permission denied

Bob

----- Forwarded *TRIMMED* message from Josselin Mouette <address@hidden> -----

From: Josselin Mouette <address@hidden>
Subject: Bug#270967: Why purging gconf2-common might erase your /etc
Date: Mon, 30 Jan 2006 10:10:57 +0100

[...TRIMMED CONTENT, ORIGINAL IN ARCHIVE...]

This error message is triggered by rmdir trying to remove /etc.
Normally, rmdir -p --ignore-fail-on-non-empty will try to
remove /etc/gconf/2, then /etc/gconf, then /etc, and will stop with /etc
because it isn't empty.

On your system, the chattr -i prevents the removal of /etc, and rmdir
fails on "permission denied" instead of "directory not empty".

I'd say that, so that rmdir -p --ignore-fail-on-non-empty can work on
such systems, it should be made to check first if the directory is
empty, and then if it has the permissions to remove it. I'm creating a
clone report on coreutils, but maybe it is caused directly by the kernel
or libc - in which case it should still be possible to work around the
issue in coreutils.

Currently, rmdir --ignore-fail-on-non-empty seems to do the following:
      * call rmdir(2)
      * check errno
      * ignore ENOTEMPTY
Maybe it could be modified to do the following:
      * check if the directory is empty
      * call rmdir(2)
I don't know whether this would be acceptable. Depending on the
coreutils maintainers' advice and decision, I will modify - or not - the
gconf2 scripts.

Regards,
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           address@hidden
`. `'                        address@hidden
   `-  Debian GNU/Linux -- The power of freedom

----- End forwarded message -----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]