I’m finding that one of the more confusing aspects of Oracle Database 11g Database File System (DBFS) for folks to understand is the difference between access and administration permissions.
The Oracle Databse 11g Database File System (DBFS) documentation discusses the “fuse” group, the allow_other DBFS mount option and the /etc/fuse.conf file but all this information doesn’t draw a clear distinction between administrative permissions and access permissions.
- Administrative Permissions. All mention the fuse group (and any mention of permissions settings on /dev/fuse) is related to permissions necessary to administer the file system (e.g., mount and unmount file systems, etc)
- Access Permissions. The allow_root and allow_other dbfs_client mount options are related to permissions to access the mounted file systems and contents of the file systems.
If the allow_other mount option is passed—when using dbfs_client to mount a file system—then other, ordinary Linux users can access file system contents as per the normal Linux file system permissions. Consider the following example. I’ll show that I have a DBFS file system mounted at /data. Next, as root, I’ll create a file called joe.txt and then modify its ownership to joe and group joe:
# mount | grep /data dbfs on /data type fuse (rw,nosuid,nodev,max_read=1048576,default_permissions,allow_other,user=oracle) # ls -ld /data /data/FS1 /data/FS1/joe.txt drwxr-xr-x 4 root root 0 Feb 10 17:30 /data drwxrwxrwx 76 oracle dba 0 Feb 10 17:27 /data/FS1 -rw-r--r-- 1 joe joe 0 Feb 10 17:27 /data/FS1/joe.txt
Next, I’ll switch user (with login) to the user joe and list joe’s file. It is owned by joe and all directory hierarchy permissions back to /data permit joe’s access, so it should be no problem:
# su - joe $ $ id uid=1001(joe) gid=1005(joe) groups=1005(joe) $ ls -l /data/FS1/joe.txt ls: /data/FS1/joe.txt: Permission denied
OK, so something is obviously wrong. Yes, there is. It is a known bug (8976604) and there is a very simple work-around. I don’t like blogging about known bugs, but I think someone will likely find this via a Google search. Allow me to explain the work-around
The work-around for bug 8976604 is to supply to pass-through-fuse-options parameter at mount time. Consider the following example:
$ $ORACLE_HOME/bin/dbfs_client dbfs@ --pass-through-fuse-options -o allow_other,direct_io /data < /opt/oracle/dbfs/passwd.txt &  2931 $ Password: $ su - joe Password: $ $ id uid=1001(joe) gid=1005(joe) groups=1005(joe)$ ls -l /data/FS1/joe.txt total 0 -rw-r--r-- 1 joe joe 0 Feb 10 17:27 /data/FS1/joe.txt
There, joe is happy now that he can see the file he owns.