Project

General

Profile

Bug #3301

cfuse: chmod not getting respected

Added by Sam Lang almost 11 years ago. Updated almost 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Sam Lang
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

echo "foo" > foo
chmod 400 foo
echo "bar" >> foo

Should fail with EPERM, but it succeeds.

Attached is a client log from the script.

client.admin.log View (216 KB) Sam Lang, 10/15/2012 07:17 AM

client.admin.log View - client log for 2nd chmod case (153 KB) Sam Lang, 10/16/2012 09:56 AM

client.admin.log View - A less confusing log of chmod issue #2 (229 KB) Sam Lang, 10/16/2012 10:19 AM

mds.a.log View (618 KB) Sam Lang, 10/16/2012 10:48 AM

client.admin.log View (126 KB) Sam Lang, 10/16/2012 10:48 AM

Associated revisions

Revision 2542dd53 (diff)
Added by Sage Weil almost 11 years ago

client: fix implemented caps update on release/flush

When we release caps, clear them out of implemented as well, unless we
still hold references. Otherwise implemented ends up holding all sorts of
extra caps (e.g., when nothing is getting revoked), leading to confusion
later down the line.

This now mirrors the kernel code.

Fixes: #3301
Signed-off-by: Sage Weil <>

History

#1 Updated by Sage Weil almost 11 years ago

yeah, apparently fuse isn't doing the check itself... :/ we should enforce this in Client::_open(), methinks. after the if/else block, before if (result >= 0)

#2 Updated by Sam Lang almost 11 years ago

Another issue:

chmod 400 a11
echo "foo" >> a11
< now fails correctly >
chmod 644 a11
ls la a11
-r------- 1 root root 4 Oct 16 11:05 a11

#3 Updated by Sam Lang almost 11 years ago

This log is of the client with only the following operations performed:

echo baz > baz
chmod 400 baz
chmod 644 baz
ls -la baz

#4 Updated by Sam Lang almost 11 years ago

This time the logs are from doing the following:

root@scout:/tmp/cmnt# echo foo > foo
root@scout:/tmp/cmnt# chmod 400 foo
root@scout:/tmp/cmnt# chmod 644 foo
root@scout:/tmp/cmnt# ls la foo
-rw-r--r- 1 root root 4 Oct 16 12:44 foo
root@scout:/tmp/cmnt# chmod 400 foo
root@scout:/tmp/cmnt# ls la foo
-rw-r--r- 1 root root 4 Oct 16 12:44 foo
root@scout:/tmp/cmnt# echo foo >> foo
root@scout:/tmp/cmnt# ls la foo
-rw-r--r- 1 root root 8 Oct 16 12:45 foo

Note that the permissions were correct after the second chmod, but not after the third, and the append should have failed.

#5 Updated by Sage Weil almost 11 years ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF