Handle IDMAP_BOTH in posix_acls.c
obnox at samba.org
Thu May 3 02:25:44 MDT 2012
thanks for sharing your patch for review. Still looking.
Generally, I think the patch would be more easily
readable if split in two: first refactor a function
add_current_ace_to_acl out and then change the behaviour.
But that is mostly cosmetical of course.
In the end it would be better to collect the sids into
a l list and call sids_to_unixids with the list to
just have one call. But that can be done as a second
step for optimization..
Andrew Bartlett wrote:
> On Thu, 2012-05-03 at 10:02 +0200, Stefan (metze) Metzmacher wrote:
> > Hi Andrew,
> > > In my s3-acls branch I have a patch to use IDMAP_BOTH in posix_acls.c
> > >
> > > I know you are both very keen to get IDMAP_BOTH properly supported in
> > > smbd, so we can support GPOs in the s3fs configuration. I'm hoping to
> > > today and tomorrow write some tests for GPO ACLs but in the meantime I
> > > think this is what we need:
> > > https://git.samba.org/?p=abartlet/samba.git/.git;a=commitdiff;h=9ae38a8f985bf04c598ab8b469226fe94e2624a5
> > I think for the IDMAP_BOTH case we should just create a GID_ACE.
> > As we put the unix id into the unix group token, it should be enough
> > to store the GID_ACE.
> I originally did that (and a minimal patch to do that just needs to call
> sid_to_gid first), but there is logic in the ACLs code that seems to
> demand that there be a SMB_ACL_USER_OBJ entry
> > We should also check, if it would be better to handle
> > SMB_ACL_USER_OBJ and SMB_ACL_GROUP_OBJ differently.
> > We might also need to change the NFSv4 mapping code...
> Is that actually connected to anything yet (in the absence on real-world
Yes, the NFSv4 mapping code is uses by e.g. the vfs modules
vfs_gpfs, vfs_zfsacl and vfs_aixacl2. These are different
backend implementations for the set/get_nt_acl methods
of the vfs api (different from the default posix_acl one).
> How do you want to proceed on this? I am certainly not an expert in
> this area, but I always feel better when I'm coding, and it helps me get
> a grip on the larger problem.
> I'm quite fine if you want to take this on from here, or to work with
> you to get a solution here in whatever way you feel will be the most
> I see this as the last blocker before flipping the --use-s3fs default
> and releasing a beta (preferably at SambaXP).
Yeah, let's see where we can get in the next couple of days.
Cheers - Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 206 bytes
Desc: not available
More information about the samba-technical