[prev in list] [next in list] [prev in thread] [next in thread] 

List:       samba-technical
Subject:    Re: NTVFS to S3FS Migration
From:       brendan powers <brendan0powers () gmail ! com>
Date:       2012-06-07 15:22:45
Message-ID: CAL2gLySHJXNxaNFC_LcHcJkVePnT4_jq1VYn561T4yu97AJoYA () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jun 6, 2012 at 10:23 PM, Andrew Bartlett <abartlet@samba.org> wrote=
:
> On Wed, 2012-06-06 at 12:45 -0400, brendan powers wrote:
>
>>
>> Thanks for your response, that sounds encouraging. After getting my
>> software to parse the new v3 xattr format, I was able to read and
>> write ACLs. Currently, I'm reading the v3, and writing back v1. This
>> part seems to work quite well. I can write new ACLs, and windows
>> clients see them as they did before. However, they don't seem to be
>> completely honored. These are the 2 cases in which I had problems.
>>
>> 1) Add a deny ACL for administrator on the sysvol share. The ACL
>> denied "Full Control" for the administrator user. In practice, you'd
>> never do this, but I was just testing. The end result was that the
>> administrator could still use the sysvol share as usual. If I were to
>> do the same thing with a normal user, it works as expected, and the
>> users is denied access.
>>
>> 2) Create a new share. Then create a folder owned by root. Then, add 2
>> ACLs. The first one allowing domain admins full control. The second
>> one allowing domain users modify access. This ACL is written in V1
>> format to the xattr of the share folder. If a user then logs in, and
>> tries to connect to the share, they get an access denied. This is
>> because the POSIX ACLs have not been updated. If I then go in as an
>> admin on a windows computer, and add an ACL for an unrelated user(say
>> read access for guest), it resolves the issue. Since I changed the
>> permissions through SMB, the POSIX attributes for the ACL are
>> correctly updated, and the original user can now access the share.
>>
>> It seems that I do need to ensure proper POSIX permissions for normal
>> operation. You mentioned two options. Either do it through SMB, or
>> through the VFS layer. Doing it through SMB sounds like the simplest
>> option. However, the SMB client library I am familiar with
>> (libsmbclient), does not allow you to set the security descriptor
>> directly. Instead you use the smbc_*xattr functions. Is there another
>> client library I should use?
>
> The python cifs client lib can set ACLs (we use it for GPO management).
>
>> Using the VFS layer directly sounds like the more flexible, and
>> faster, option. However, I have no idea how to go about doing this. Is
>> it just a matter of making the right API calls on a shared library?
>
> Sort of. =A0The VFS isn't intended to be called directly, but it can be
> made to work (like vfstest does).
>
>> Sorry, forgot to reply to the list for the last message.
>
> In any case, I think this is a bug in acl_xattr. =A0My understanding was
> that we should have overridden the conflicting posix permissions in this
> case. =A0 Please file a bug.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0http://samba.org/~abartlet/
> Authentication Developer, Samba Team =A0 =A0 =A0 =A0 =A0 http://samba.org
>

Ok, I have filed a bug (#8987). I also filed a bug for the "The
parameter is incorrect" issue (#8986).

While I agree that this is an issue with acl_xattr, and all I really
need is the V1 xattrs to be honored, it would be nice to also make
sure the POSIX ACLs are up to date.

On a side note, what does the hash in the V2, and V3 xattrs do? I
imagine it let's Samba know when the POSIX and NT permissions do not
match. What does Samba do when the hash doesn't match the underlying
ACL?
[prev in list] [next in list] [prev in thread] [next in thread]