Skip to content

Conversation

@rminnich
Copy link

The open flag indicates the type of access we need.

Add a test to the memfs server to make sure an open
is blocked if the flags and permissions don't match.

Signed-off-by: Ronald G. Minnich rminnich@gmail.com

fuseops/ops.go Outdated
// advance, for example, because contents are generated on the fly.
UseDirectIO bool

// Open flags. See os.OpenFile
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Open flags. See os.OpenFile
// User-provided flags to open(2). See http://go/godoc/os/#OpenFile.

if !inode.isFile() {
panic("Found non-file.")
}
// What perms do we need?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had trouble understanding what you were doing here at first. Could you make
the code read something like:

// Check that the open mode is legal according to the file
// permissions.
var permissionBits int
switch (...) {
    ...
}

if (...) {
  err = EACCESS
  return
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should not be checking attributes, since they can change behind our back.

case unix.O_RDWR:
perm = 0600
// This is legal, at least on linux
case unix.O_ACCMODE:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This case is weird, and I think it's just an artifact of using a switch
statement, right? Why not something like:

if flags & unix.O_RDONLY && !(inode.attrs.Mode()&unix.O_RDONLY) {
  return EACCESS
}

// Ditto with O_WRONLY and O_RDWR
...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah, and that case is very deliberate: I tested it on linux before I added it. Again, I broke it out b/c it's not obvious.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops, I was thinking about the fs I am writing, not memfs, sorry. nvm.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if you want it to work your proposed way that's fine too.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I'm totally lost at this point. All I want you to do in memfs_test is somehow confirm that the open(2) flags correctly come through to the file system. Maybe you are attempting to do that here, but I don't understand how. Could you please improve the commenting, here or in the test, to explain how you're confirming this?

The open flag indicates the type of access we need.

Add a test to the memfs server to make sure an open
is blocked if the flags and permissions don't match.

Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
@rminnich rminnich force-pushed the addflagtoopencreate branch from f13b68c to c004db6 Compare May 21, 2019 14:22
complyue added a commit to complyue/jdfs that referenced this pull request Jun 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants