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 & [1] 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.
Interesting part is that dbfs_client has an option that passes this information along, but it doesn’t work. The –pass-through-fuse trick works great.
from the -h for dbfs_client
-o allow_root Allows root access to the filesystem.
This option requires setting
‘user_allow_other’ parameter in
‘/etc/fuse.conf’.
-o allow_other Allows other users access to the file
system.
It is a bug that is already fixed. It only relates to 11.2.0.1
The above fixed a long standing issue about 2 months ago… Sorry didn’t get a chance to ping back earler… Really happy with DBFS over the past 2 months and bundle patch 3 (9524394) has numerous fixes which should further help stability..
Ta
Fairlie