stat() fails with EPERM on ~/.gvfs

[Vovapike]

While it is known that root can not access the contents of the .gvfs directory by design, stat() on the directory itself also fails with EPERM despite the fact that root has read permission on the parent directory. stat() on the mount point needs to succeed and should probably return a mode indicating no access is allowed. Simply determining that the directory IS a mount point and that you do not have access to its contents requires the use of stat.

[Sebastien Bacher (seb128)]

thank you for your bug report, could you run ls -ld .gvfs on a command line and copy that to a comment?

[Vovapike (vovapike1982)]

ls -ld .gvfs
>>dr-x------ 2 vladimirschuka vladimirschuka 0 2008-05-28 15:08 .gvfs

[Sebastien Bacher (seb128)]

seems to be a mc bug

[Phillip Susi (psusi)]

Seems to be a bug in mc where it reports bogus information when it fails to stat() the file. When you run mc as root with sudo, it can not access files in .gvfs.

[Yury V. Zaytsev (zyv)]

I can reproduce this on Lucid. But what the behavior of mc should be in such a case??? Right now it shows the question mark and highlights the file with red. Some date has to be present, because that's how UI works. Same applies to broken links (prefixed with ! character).

Unless you can explain what would be the correct behavior in your opinion I am tempted to close this as invalid.

[Phillip Susi (psusi)]

I agree, this is probably not a bug in mc but rather should be fixed in the kernel. stat() should never fail on a file in a directory you can read.

[Yury V. Zaytsev (zyv)]

Hi Phillip!

Could you please take care of re-assigning this bug to a correct entity? I am not involved in kernel development and I have no clue what would be the correct point of contact.

Thanks,
--Yury.

[Yury V. Zaytsev (zyv)]

Many thanks!

[penalvch (penalvch)]

Vovapike, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Phillip Susi (psusi)]

Please don't downgrade triaged bugs to incomplete without at least trying to reproduce the problem yourself. There hasn't been activity because it has not been fixed. The directory has however, been moved from ~/.gvfs to /run/user/id/gvfs.