stat() fails with EPERM on ~/.gvfs

Bug #235412 reported by Vovapike
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned

Bug Description

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Vovapike (vovapike1982) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

seems to be a mc bug

Changed in gvfs:
assignee: desktop-bugs → nobody
status: Incomplete → New
Revision history for this message
Phillip Susi (psusi) wrote :

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.

Changed in mc:
status: New → Triaged
Revision history for this message
Yury V. Zaytsev (zyv) wrote :

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.

Changed in mc (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Phillip Susi (psusi) wrote :

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.

Revision history for this message
Yury V. Zaytsev (zyv) wrote :

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.

Phillip Susi (psusi)
affects: mc (Ubuntu) → linux (Ubuntu)
summary: - ?.gvfs files zero size
+ stat() fails with EPERM on ~/.gvfs
description: updated
Changed in linux (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Yury V. Zaytsev (zyv) wrote :

Many thanks!

Revision history for this message
Christopher M. Peñalver (penalvch) wrote :

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.

Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Phillip Susi (psusi) wrote :

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.

Changed in linux (Ubuntu):
status: Expired → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers