NTVFS to S3FS Migration

[brendan powers]

On Wed, Jun 6, 2012 at 12:41 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Tue, 2012-06-05 at 20:15 -0400, brendan powers wrote:
>> Since the release of Alpha21, I've been looking into implementing S3FS
>> in existing NTVFS installations. For the most part, it's fairly
>> simple. Just added the needed entries to the existing smb.conf file.
>> There is one sticky point however, and that is upgrading to the new
>> permission format. In the past, NTVFS has simply stored the security
>> descriptor in the seciry.NTACL xattr. Now, with the introduction of
>> S3FS this format has changed to the security descriptor, plus a hash
>> of the POSIX permissions. As I understand it, if the hash in the xattr
>> does not match the actual POSIX permissions, the NT descriptor is
>> thrown out, and then re-built from using the POSIX permissions as a
>> starting point.
>>
>> So, at the moment, I'm trying to figure out how to upgrade to S3FS and
>> preserve any existing NTVFS permissions. As well as migrating new
>> installations, Resara  Server (the product I work on that's currently
>> using NTVFS) edits the security attributes in security.NTACL directly.
>> So I also need a way to edit permissions in S3FS on an ongoing basis.
>> As I see it, here are my options.
>
> G'day Brendan,
>
> The 'old' security.NTACL xattr format is honoured in preference to any
> other ACL.  We actually need this long-term, as we can't set the posix
> ACL during the provision, so the group policy objects are still (even
> with s3fs) being written in the NTVFS format.
>
> So, there shouldn't be any short-term migration pain.
>
> Once we have installed and have a file server up and running, you could
> of course walk the filesystem using a python script, and either over SMB
> or directly read the NT ACL, and then set it via the VFS, to gain
> matching posix permissions.
>
> I hope this clarifies things.  We really don't want to leave you in the
> cold, particularly as you have been such an important early adopter of
> Samba4.
>
> Naturally, the above is subject to bugs and unexpected surprises.  If it
> doesn't work like that, then we need to make it work like that!  :-)
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
>

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?

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?

Sorry, forgot to reply to the list for the last message.