1

I have a FUSE filesystem in which I coded the getxattr and setxattr like this:

int mfs_setxattr(const char *path, const char *name, const char *value, size_t size, int flags)
{
  ... /* some translation processing of path to rpath */

  int ret = lsetxattr(rpath, name, value, size, flags);

  ... /* some logging works */

  if (ret == -1) {
    return -errno;
  }

  return 0;
}

and

int mfs_getxattr(const char *path, const char *name, char *value, size_t size)
{
  ... /* some translation processing of path to rpath */

  int ret = lgetxattr(rpath, name, value, size);

  ... /* some logging works */

  if (ret == -1) {
    return -errno;
  }

  return ret;
}

I have tested this and it work very well except for capabilities: when I use setcap to set a capability for a program and run it, the program can't perform the privileged work. Despite getcap returns the capability that I setted earlier.

Can someone tell me a way to track the problem or give me some pointers about what is going on?

tomix86
  • 1,336
  • 2
  • 18
  • 29
nsstl
  • 15
  • 5

1 Answers1

-1

I think a good place to start is the init function. There you get as an argument a

struct fuse_conn_info *conn

This struct contains the following fields

  1. proto_major: major version of FUSE
  2. proto_minor: minor version of FUSE
  3. async_read: if this entry is > 0 then your FS supports async reads
  4. max_write: what's the max-write that supported. If you put a value that is lees than 4K it will directly revert the value to 4K
  5. max_readahead: max readahead value
  6. capable: This is what capabilities the FUSE kernel module supports It's encoded as bit flags
  7. want: what capabilities the FUSE client wants, again bit encoded

Now I haven't experimented with this yet but I bet the "want" field is that you need to modify. The options that you have are the following

  • FUSE_CAP_DONT_MASK: if set, umask is not applied to files on create ops. Some on the net claim that is not really implemented
  • FUSE_CAP_EXPORT_SUPPORT: says if your client handles "." or ".." itself or FUSE needs to perform a trap and handle it
  • FUSE_CAP_ASYNC_READ: if you basically use async reads or not, this is enabled by default
  • FUSE_CAP_BIG_WRITES: Should be set if the FS can handle bigger writes than 4KB
  • FUSE_CAP_POSIX_LOCKS: Should be set if the FS client supports locking from remote entities via the lock system call
  • FUSE_CAP_ATOMIC_O_TRUNC: if the FS supports O_TRUNC as an open flag, this should be set

I'm not sure how helpful this is, but it's a start. There are some threads that people say that if you can actually disable somehow the capabilities you get great performance gains. But I still haven't found how to do that.

Vasileios Lekakis
  • 5,492
  • 2
  • 15
  • 17
  • 1
    thinks for your response, but what I want are not capabilities for my fs program. My fuse fs has to replicate the exact behavior in the underlying directory, I have all operations deplucated successfuly ecxept for capabilities: - if in the monitored directory you have some program that require capabilities, you can set them with setcap and retrieve them with getcap. - but if you execute that program, it won't get these capabilities and fail. – nsstl Nov 22 '12 at 11:43