gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] xlator uid/guid question


From: Angel
Subject: Re: [Gluster-devel] xlator uid/guid question
Date: Sat, 19 Jan 2008 20:25:39 +0100
User-agent: KMail/1.9.6 (enterprise 20070904.708012)

Hi August

One direct source to learn what things happen is looking at the same function 
on the posix-storage module.

that's how posix-storage process create 


...
  SET_FS_UID (frame->root->uid, frame->root->gid);

  if (!flags) {
    _fd = open (real_path,
                O_CREAT|O_RDWR|O_EXCL,
                mode);
  } else {
    _fd = open (real_path,
                flags|O_CREAT,
                mode);
  }

  op_errno = errno;

  if (_fd >= 0) {
      /* trigger readahead in the kernel */
#if 0
    char buf[1024 * 64];
    read (_fd, buf, 1024 * 64);
    lseek (_fd, 0, SEEK_SET);
#endif
#ifndef HAVE_SET_FSID
    chown (real_path, frame->root->uid, frame->root->gid);
#endif
    fstat (_fd, &stbuf);

  }
  SET_TO_OLD_FS_UID ();
....


So it seems that   SET_FS_UID (frame->root->uid, frame->root->gid);

looks for the uid and gid of the calling context, Remember that usually 
glustefsd runs at root uid.

So you can alter these values on your create function , prior to passing tha 
call downwards,

Try it but just wait some devs assure you that this is correct.

Regards, Angel

El Sábado, 19 de Enero de 2008 August R. Wohlt escribió:
> Hi glusterfs hackers,
> 
> I am trying to write a simple xlator similar to the fixed-id one that comes
> with the source code.
> 
> The fixed-id xlator passes all calls through to the underlying volume and
> then mangles the uid and gid of the stat structures on the way back to the
> client, so what you end up with when looking at a mount is a directory of
> files that appear to be owned by a fixed uid.gid, but really on the
> underlying volume, they are created as the original user, which can cause
> interesting permission issues.
> 
> I would like to modify this behavior so that the files get created on the
> underlying volume with the fixed-id as well (even if just for the
> superuser). I can do this in the chown functions with something like this
> easy enough:
> 
>  struct fixed_id *id = (struct fixed_id *)this->private;
>   if (id->fixed_uid_set) uid = id->fixed_uid;
> 
> before the STACK_WIND, and it works when I chown a file on the mount, but
> how do I intercept the uid when a file is being created in the first place?
> I don't see any arguments to create() that are applicable. Does fuse just
> use the user from the calling process to do this?
> 
> 
> cheers,
> august
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
> 



-- 
------------------------------------------------
Clist UAH @gmail!!
------------------------------------------------




reply via email to

[Prev in Thread] Current Thread [Next in Thread]