Bug 61868 - umount by user permission problem
umount by user permission problem
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: mount (Show other bugs)
skipjack-beta1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-25 07:42 EST by Volkov Oleg
Modified: 2007-04-18 12:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-11 23:42:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Tracefile by "strace -f -F -i -o mtr -s 256 -u voleg umount /mnt/cdrom" (9.67 KB, text/plain)
2002-03-26 06:50 EST, Volkov Oleg
no flags Details
patch to correct problem (436 bytes, patch)
2002-03-31 12:25 EST, Jay Berkenbilt
no flags Details | Diff

  None (edit)
Description Volkov Oleg 2002-03-25 07:42:03 EST
umount do actually its job but does not update mtab. 
eject and all X environments that use eject inherit this problem. 
 
Small test: 
 
voleg]$ grep cdrom /etc/fstab 
/dev/cdrom              /mnt/cdrom              iso9660 noauto,owner,kudzu,ro 0 0 
voleg]$ mount /mnt/cdrom 
voleg]$ mount 
..... 
..... 
/dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) 
 
voleg]$ umount /mnt/cdrom 
cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated 
voleg]$ mount 
..... 
..... 
/dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) 
 
voleg]$ mount /mnt/cdrom 
voleg]$ mount 
..... 
..... 
/dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) 
/dev/cdrom on /mnt/cdrom type iso9660 (ro,nosuid,nodev,user=voleg) 
 
voleg]$ umount /mnt/cdrom 
umount: it seems /mnt/cdrom is mounted multiple times
Comment 1 daniel 2002-03-25 15:38:48 EST
This is happening on my box as well.
Comment 2 Elliot Lee 2002-03-25 15:43:06 EST
I can't reproduce the problem here, with mount-2.11n-9 installed. The heart of
the problem is the failure to create mtab.tmp, which I do not see.

Any weird things in your environment that would cause this?
Comment 3 daniel 2002-03-25 20:22:33 EST
This is what i have done: 
 
AFter a fresh install (everything option) I boot into kde.  Second, I insert a cd (this 
happens to be the skipjack SRPMS disk) and 'mount /mnt/cdrom' .  Below is my sequence of 
commands, at the end you can see /dev/cdrom mounted twice.  Hope this helps, if you need 
more info, feel free to contact me 
 
DanC (dan_cunningham@ecovate.com) 
 
 
[daniel@dansquake daniel]$ df  
Filesystem           1k-blocks      Used Available Use% Mounted on  
/dev/sda3             16690232   3467084  12375320  22% /  
/dev/sda1                31079      5981     23494  21% /boot  
none                    257192         0    257192   0% /dev/shm  
[daniel@dansquake daniel]$ mount /mnt/cdrom  
[daniel@dansquake daniel]$ df  
Filesystem           1k-blocks      Used Available Use% Mounted on  
/dev/sda3             16690232   3467084  12375320  22% /  
/dev/sda1                31079      5981     23494  21% /boot  
none                    257192         0    257192   0% /dev/shm  
/dev/cdrom              654002    654002         0 100% /mnt/cdrom  
[daniel@dansquake daniel]$ umount /mnt/cdrom  
cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated  
[daniel@dansquake daniel]$ df  
Filesystem           1k-blocks      Used Available Use% Mounted on  
/dev/sda3             16690232   3467084  12375320  22% /  
/dev/sda1                31079      5981     23494  21% /boot  
none                    257192         0    257192   0% /dev/shm  
/dev/cdrom            16690232   3467084  12375320  22% /mnt/cdrom  
[daniel@dansquake daniel]$ umount /dev/cdrom  
umount: /dev/cdrom: not mounted  
[daniel@dansquake daniel]$ df  
Filesystem           1k-blocks      Used Available Use% Mounted on  
/dev/sda3             16690232   3467084  12375320  22% /  
/dev/sda1                31079      5981     23494  21% /boot  
none                    257192         0    257192   0% /dev/shm  
[daniel@dansquake daniel]$ eject  
[daniel@dansquake daniel]$ umount /mnt/cdrom  
umount: /mnt/cdrom is not mounted (according to mtab)  
[daniel@dansquake daniel]$ mount /mnt/cdrom  
[daniel@dansquake daniel]$ eject  
cannot open /etc/mtab.tmp (Invalid argument) - mtab not updated  
[daniel@dansquake daniel]$ mount /dev/cdrom  
[daniel@dansquake daniel]$ cd /mnt/cdrom  
[daniel@dansquake cdrom]$ ls  
beta_eula.txt  README-Accessibility  RPM-GPG-KEY-beta  TRANS.TBL  
README         RPM-GPG-KEY           SRPMS  
[daniel@dansquake cdrom]$ cd  
[daniel@dansquake daniel]$ umount /dev/cdrom  
umount: it seems /dev/cdrom is mounted multiple times  
[daniel@dansquake daniel]$ df  
Filesystem           1k-blocks      Used Available Use% Mounted on  
/dev/sda3             16690232   3467084  12375320  22% /  
/dev/sda1                31079      5981     23494  21% /boot  
none                    257192         0    257192   0% /dev/shm  
/dev/cdrom              654002    654002         0 100% /mnt/cdrom  
/dev/cdrom       654002    654002         0 100% /mnt/cdrom  
[daniel@dansquake daniel]$  
Comment 4 daniel 2002-03-25 20:24:32 EST
 By the way, you can also see I'm doing this from a unpriviledged account (non root), 
might be inportant?
Comment 5 Volkov Oleg 2002-03-26 01:59:20 EST
Tried to downgrade to mount 2.11g (from rh72), the problem persistant.
So it is not a problem with mount package. Still digging.
Comment 6 Volkov Oleg 2002-03-26 06:50:08 EST
Created attachment 50444 [details]
Tracefile by "strace -f -F -i -o mtr -s 256 -u voleg umount /mnt/cdrom"
Comment 7 Volkov Oleg 2002-03-26 06:59:13 EST
According tracefile an /etc/mtab.tmp attempted to create with 0666 mode.
Actually created file has permissions:
$ ll /etc/mtab.tmp
-rw-r--r--    1 root     voleg           0 Mar 26 13:53 /etc/mtab.tmp
and still in /etc directory.

Permissions for /etc:
$ ll -d /etc
drwxr-xr-x   53 root     root         8192 Mar 26 13:54 /etc
Comment 8 Elliot Lee 2002-03-26 10:29:05 EST
The mode passed to open() is combined with the user's umask, explaining the
difference.

The curious thing is that the open() is succeeding but somehow the fopen() is
seen as failing.

Until it is something that I can reproduce on my system, all I can do is try to
help you guys track down the problem.
Comment 9 Volkov Oleg 2002-03-26 14:06:31 EST
Yes, but my umask (nether thught about it) is 002
that should cause in -rw-rw-r-- permissions , and not
as above. The file /etc/mtab.tmp created with group voleg,
may be umount want to write it using uid voleg through group
permissions. In this case group permissions does not allow to write
to this file.

To differ with Daniel installation, that claimed ti be clean install,
my installation was upgrade from RH7.2 . What common to that
installation? I cleaned environment with unset and unalias commands,
but still having this behaviour. Do you think, "rpm -qa" would help ?
Comment 10 Volkov Oleg 2002-03-27 08:17:19 EST
# ldd /bin/umount
        libc.so.6 => /lib/i686/libc.so.6 (0x40025000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
# ll /lib/i686/libc.so.6
lrwxrwxrwx    1 root     root           13 Mar 24 17:33 /lib/i686/libc.so.6 ->
libc-2.2.5.so
# ll /lib/i686/libc-2.2.5.so
-rwxr-xr-x    1 root     root      1400136 Mar 14 22:34 /lib/i686/libc-2.2.5.so

A long time ago libc has more than 5M. This size is very strange.
# rpm -qf /lib/i686/libc-2.2.5.so
glibc-2.2.5-27
#  rpm -V glibc
.......T c /etc/rpc
Comment 11 Elliot Lee 2002-03-27 14:23:31 EST
Can't reproduce it on another clean-install system here either, although the
behaviour has been spotted. Very strange.
Comment 12 Volkov Oleg 2002-03-28 21:39:25 EST
Because I tried to downgrade to stable mount package from rh7.2
and still have the same problem, a problem is not in mount.

Mount is linked with libc, wich comes with glibc-2.2.5-27 rpm.
As pointed above abnormal size of this libc may show a problem.

A bug number 62280 was opened to glibc guys. 

I suppose to get an updated glibc to verify this, and close the subject.
Comment 13 Elliot Lee 2002-03-29 12:33:01 EST
It's not likely this is a glibc problem (and, seeing as how jakub gave a correct
response to the other bug, you know that now :)

Most likely it's some odd thing in the environment. Others around here have seen
the problem on rare occasions, but have not been able to reproduce it. Most
likely this will wind up staying unfixed until someone here can reproduce the
problem reliably.
Comment 14 Jay Berkenbilt 2002-03-31 12:24:46 EST
This is a trivial bug in mount in the error checking code.  I'm attaching a
patch.  After applying this patch, the problem seems to be gone.

My patch should be applied to fstab.c in util-linux-2.11n/mount.  It is
constructed such that you can apply it with -p1 from the util-linux-2.11n build
directory.
Comment 15 Jay Berkenbilt 2002-03-31 12:25:53 EST
Created attachment 51564 [details]
patch to correct problem
Comment 16 Jay Berkenbilt 2002-04-11 23:41:57 EDT
Any reason that this bug is still open?  I see the patch has been applied in -11
and that it is included in beta2.
Comment 17 Elliot Lee 2002-04-12 10:13:30 EDT
Yea, patch applied, thanks.

Note You need to log in before you can comment on or make changes to this bug.