Bug 422941 - fuseiso -p removes existing (empty) directory regardless of owner
fuseiso -p removes existing (empty) directory regardless of owner
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: fuseiso (Show other bugs)
8
i686 Linux
low Severity urgent
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-13 02:29 EST by Philip Ashmore
Modified: 2007-12-13 07:16 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-13 07:16:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Philip Ashmore 2007-12-13 02:29:20 EST
Description of problem:
fuseiso -p removes existing (empty) directory regardless of owner

Version-Release number of selected component (if applicable):
20070708-2.fc8

How reproducible:
Always

Steps to Reproduce:
1. # chown 500:500 /opt
2. # mkdir /opt/test
3. $ fuseiso -p ~/my-cd.iso /opt/test
  
Actual results:
fusermount: user has no write access to mountpoint /opt/test
/opt/test gets deleted!

Expected results:
Can`t create mount point: Permission denied
(this is what happens when I try fuseiso -p ~/my-cd.iso /test)

Additional info:
Comment 1 Tom "spot" Callaway 2007-12-13 07:16:49 EST
OK. Lets look at this.

Step 1: Set ownership of /opt to the uid 500, gid 500. I'm assuming that is your
normal, unprivileged user, since Fedora creates the first user at 500.
[root@localhost /]# ls -n |grep opt
drwxr-xr-x   2 500 500       4096 2007-12-13 06:50 opt

Step 2: Create a new directory under /opt as root.
[root@localhost /]# mkdir /opt/test
[root@localhost /]# ls -l /opt/
total 8
drwxr-xr-x 2 root root 4096 2007-12-13 06:53 test

There it is, owned by root. Now, lets try to delete it by hand, with uid 500
(for me, that is spot).

[spot@localhost ~]$ ls -l /opt
total 8
drwxr-xr-x 2 root root 4096 2007-12-13 06:57 test
[spot@localhost ~]$ rm -rf /opt/test/
[spot@localhost ~]$ ls -l /opt
total 0
[spot@localhost ~]$ 

What? How did I do that? Lets try a different unprivileged user, foo (uid 5114)
First, we'll recreate the /opt/test directory as root, and confirm the
permissions on /opt:

[root@localhost /]# ls -n / |grep opt
drwxr-xr-x   3 500 500       4096 2007-12-13 07:03 opt
[root@localhost /]# mkdir /opt/test
[root@localhost /]# ls -l /opt/
total 8
drwxr-xr-x 2 root root 4096 2007-12-13 07:05 test

Now, we'll su - foo, then try to delete /opt/test manually:
[spot@localhost ~]$ su - foo
Password: 
[foo@localhost ~]$ ls -l /opt/
total 8
drwxr-xr-x 2 root root 4096 2007-12-13 07:05 test
[foo@localhost ~]$ rm -rf /opt/test
rm: cannot remove directory `/opt/test': Permission denied

OK, now, we'll try it as spot (500) again, just to confirm:
[spot@localhost ~]$ ls -l /opt
total 8
drwxr-xr-x 2 root root 4096 2007-12-13 07:05 test
[spot@localhost ~]$ rm -rf /opt/test
[spot@localhost ~]$

So, what's going on here? This is one of the vagaries of chowning directories.
Whomever owns the toplevel directory implicitly owns all the bits underneath.
Thus, uid 500 is free to delete /opt/test, even though that directory is owned
by root, because /opt is owned by uid 500.

You need to be especially careful when you use chown to give ownership of
directories for this specific reason.

This one really isn't fuseiso's fault, since it is doing what chown will let it
do. Clear as mud, I admit, but not really a bug.

Note You need to log in before you can comment on or make changes to this bug.