Bug 422941

Summary: fuseiso -p removes existing (empty) directory regardless of owner
Product: [Fedora] Fedora Reporter: Philip Ashmore <contact>
Component: fuseisoAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 8   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-13 12:16:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Philip Ashmore 2007-12-13 07:29:20 UTC 
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 12:16:49 UTC 
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.