February 11, 2010 5:38 am
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.
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.
Posted by kevinclosson
Categories: oracle
Tags:
You must be logged in to post a comment.
Mobile Site | Full Site
Get a free blog at WordPress.com Theme: WordPress Mobile Edition by Alex King.
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.
By Steve D on February 15, 2010 at 2:14 pm
It is a bug that is already fixed. It only relates to 11.2.0.1
By kevinclosson on February 15, 2010 at 5:17 pm
[…] Kevin Closson-Oracle Database 11g Database File System (DBFS). Common DBFS Problems and Solutions. Part II. […]
By Blogroll Report 05/02/2009 – 12/02/2010 « Coskan’s Approach to Oracle on March 10, 2010 at 2:28 am
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
By Fairlie Rego on May 12, 2010 at 2:55 am