Bug 917678

Works for me:

[root@el6 ~]# echo "tmpfs  /omd/sites/test/tmp tmpfs noauto,user,mode=755,uid=test,gid=test 0 0 " >> /etc/fstab
[root@el6 ~]# mkdir -p /omd/sites/test/tmp
[root@el6 ~]# useradd test
[root@el6 ~]# su - test -c 'mount /omd/sites/test/tmp'

[root@el6 ~]# findmnt --mtab /omd/sites/test/tmp
TARGET              SOURCE FSTYPE OPTIONS
/omd/sites/test/tmp tmpfs  tmpfs  rw,noexec,nosuid,nodev,mode=755,uid=500,gid=500,user=test

[root@el6 ~]# rpm -qf /bin/mount
util-linux-ng-2.17.2-12.9.el6.i686

Please, try mount with -v (verbose mode), for example:

su - test -c 'mount -vvv /omd/sites/test/tmp'

I checked it here with yet another installation, but all our installation x86_64. Maybe it is only 64bit.
Output with -vvv:

[root@XXXXX ~]# su - test -c 'mount -vvv /omd/sites/test/tmp'
mount: fstab path: "/etc/fstab"
mount: mtab path:  "/etc/mtab"
mount: lock path:  "/etc/mtab~"
mount: temp path:  "/etc/mtab.tmp"
mount: UID:        500
mount: eUID:       0
mount: can't find /omd/sites/test/tmp in /etc/fstab or /etc/mtab

I have the exact same problem (also with OMD), and it's not the user option. It's the fact that the path in /etc/fstab contains a symlink (/omd is a symlink to /opt/omd)

Replacing /omd with /opt/omd in /etc/fstab (effectively resolving the symlink) makes this work again.

Probably something from the fix in https://bugzilla.redhat.com/show_bug.cgi?id=892330 broke this.

I can confirm comment #3. It only happens when a symlink is part of the path.

You're right.

The old code in mount/fstab.c: getfs_by_dir() does not expect non-canonical paths in fstab, but now (since bug #892330) all paths from non-root users are always canonicalized.

The workaround is to use canonicalized (real) paths in /etc/fstab for user mounts, something like:

echo "tmpfs $(cd /omd/sites/test/tmp; pwd -P) tmpfs noauto,user,mode=755,uid=test,gid=test 0 0 " >>  /etc/fstab

If I understand BZ892330 correctly the patch should fix a problem where a normal user can create a symlink and detect by the error message if a file exist even when the user can not look into the directory.

By fixing this problem, instead of checking if a symlink is resolvable by the user, the patch disabled the usage of symlinks completly for non-users.

Do I understand the problem correctly?

I have already a workaround, because I mount the tmpfs directory as user root. Not nice but working.

But I think this should be fixed permanently. There a lot of omd Users that complain about broken RHEL6.4.

(In reply to comment #6)
> If I understand BZ892330 correctly the patch should fix a problem where a
> normal user can create a symlink and detect by the error message if a file
> exist even when the user can not look into the directory.

Yes.

> By fixing this problem, instead of checking if a symlink is resolvable by
> the user, the patch disabled the usage of symlinks completly for non-users.

No, the old code used root permissions (as mount(8) is suid) to evaluate sysmlinks, the new fixed version uses non-root user's UID to evaluate paths from command line and then the new canonical path is used for all next operations in mount(8). 

Unfortunately some another part of the mount(8) command does not expect canonical paths if there is a symlink in fstab... 

It means that bug #892330 helps us to find another fragile code in mount(8).

(Fortunately, we don't use this code in RHEL7 any more.)

> But I think this should be fixed permanently. 

Sure, it's obvious bug.

Created attachment 709415 [details]
proposed patch

with the patch:

mkdir -p /mnt/test
ln -s /mnt/test /mnt/sym-test

echo "tmpfs /mnt/sym-test tmpfs noauto,user,mode=755  0 0" >> /etc/fstab

as non-root user:
   $ mount /mnt/sym-test

findmnt /mnt/test
TARGET    SOURCE FSTYPE OPTIONS
/mnt/test tmpfs  tmpfs rw,nosuid,nodev,noexec,relatime,mode=755,uid=1000,gid=1000

the patch works and fixes the problem. I created a rpm and installed it on one machine.

Any ETA for this bug in RHEL6.4?

@Marcel Kolaja: Why did you mark this bug as private? Please open it up again!

Reinstating this as a public entry. Let's leave the private BZ dance for a 6.4.z clone.

(In reply to comment #15)
> @Marcel Kolaja: Why did you mark this bug as private? Please open it up
> again!

Sorry, I did that by mistake. Ray already fixed that. Thanks Ray!

A test repo can be found at http://jens.fedorapeople.org/rhel64-bz917678/.
If you want to check the patch.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1648.html