samba - Jan 2023 - Fwd: Can Samba just store ACL information (without interpreting it) without AD?

Hi,

I read several articles on the internet, but I fail to understand how
ACL storage technically works. Of course in almost any case, ACL
should not only be stored but also evaluated, and for this this Samba
server needs to be a member of the AD domain. I think I understand
this, but I have a different use case. I hope someone can help and
possibly has a link or such.

I have a samba instance solely for backups, and there is no need to
interpret any ACL. Of course, for security reasons, I do not want a
backup server in AD. There is no access from the file system either.
No ordinary account shall work, only host-specific access accounts
shall be allowed to connect (I created them with smbpasswd). Samba
should just keep the ACL information, but in no way interpret it. A
possible restore would be done through the network, so Samba should
"return" the previously stored ACL/security information. To allow
simple file-based incremental backups, no archive format is used (but
preferably robocopy.exe).

Is this possible? Is it possible to configure a Samba server capable
of storing ACLs lossless without being a domain member?

So I would like to robocopy files with complex ACLs to this instance
and from there back to a domain member and see the same complex ACLs.

I spent some hours reading and trying, but I did not get it working
and any hint is appreciated!

I have another backup target, some QNAP NAS system (I assume it is
using Samba as well). This also does not support storing ACL security
information, but it behaves differently. A script copies data with
robocopy and the following options:

/E /COPY:DAT /PURGE /IA:RASHNTCEO /X /R:0 /W:0 /NP /TEE /FFT %ZPAR%
/LOG+:%log%

When I do the same to my Samba, I get a lot of "ERROR 5 (0x00000005)
Changing File Attributes" errors.

I run Samba on ZFS on Linux in a container, Proxmox based. xattrs seem to work:

root at nas2:/mp0/storage/backup# touch userattr
root at nas2:/mp0/storage/backup# setfattr -n user.steffen -v washere userattr
# file: userattr
user.steffen="washere"

but not for security:

root at nas2:/mp0/storage/backup# touch secattr
root at nas2:/mp0/storage/backup# setfattr -n security.NTACL -v 1 secattr
setfattr: secattr: Operation not permitted

(the same works on the proxmox host; the container is not privileged).
Because of "acl_xattr:ignore system acls", I think
"security.*" fattrs
won't be used but something like "user.samba...." or so.

NB: On file systems, permissions and ACLs do not need to work, there
is no access to filesystem, neither host nor guest, only via Samba.
Only the remote client (robocopy.exe) should be able to correctly copy
the values back.

Any hints appreciated!

Thanks and best regards,
Steffen

My config:

[global]
   workgroup = bakwg3
;   interfaces = 10.221.12.0/24 eth0
;   bind interfaces only = yes

   log file = /var/log/samba/log.%m
   log level = 1 auth_audit:3
   max log size = 1000
   logging = file
   panic action = /usr/share/samba/panic-action %d

   server role = standalone server
   obey pam restrictions = yes
   map to guest = bad user
   usershare allow guests = no

   vfs objects = acl_xattr
   map acl inherit = yes
   server signing = auto
   client signing = auto
   acl_xattr:ignore system acls = yes

   inherit acls = yes
   inherit owner = yes
   inherit permissions = yes
   map acl inherit = yes
   nt acl support = yes

   # desperate attempt without effect:
   ntlm auth = yes

[backup]
   comment = Storage Space (simulating NAS)
   path = /mp0/storage/backup
   browseable = no
   guest ok = no
   read only = no
   create mask = 0600
   directory mask = 0600
   valid users = [dedicated local backup accounts]

On 12/01/2023 13:54, Steffen Dettmer via samba wrote:
> Hi,
> 
> I read several articles on the internet, but I fail to understand how
> ACL storage technically works. Of course in almost any case, ACL
> should not only be stored but also evaluated, and for this this Samba
> server needs to be a member of the AD domain. I think I understand
> this, but I have a different use case. I hope someone can help and
> possibly has a link or such.
> 
> I have a samba instance solely for backups, and there is no need to
> interpret any ACL. Of course, for security reasons, I do not want a
> backup server in AD. There is no access from the file system either.
> No ordinary account shall work, only host-specific access accounts
> shall be allowed to connect (I created them with smbpasswd). Samba
> should just keep the ACL information, but in no way interpret it. A
> possible restore would be done through the network, so Samba should
> "return" the previously stored ACL/security information. To allow
> simple file-based incremental backups, no archive format is used (but
> preferably robocopy.exe).
> 
> Is this possible? Is it possible to configure a Samba server capable
> of storing ACLs lossless without being a domain member?
> 
> So I would like to robocopy files with complex ACLs to this instance
> and from there back to a domain member and see the same complex ACLs.
> 
> I spent some hours reading and trying, but I did not get it working
> and any hint is appreciated!
> 
> I have another backup target, some QNAP NAS system (I assume it is
> using Samba as well). This also does not support storing ACL security
> information, but it behaves differently. A script copies data with
> robocopy and the following options:
> 
> /E /COPY:DAT /PURGE /IA:RASHNTCEO /X /R:0 /W:0 /NP /TEE /FFT %ZPAR%
> /LOG+:%log%
> 
> When I do the same to my Samba, I get a lot of "ERROR 5 (0x00000005)
> Changing File Attributes" errors.
> 
> I run Samba on ZFS on Linux in a container, Proxmox based. xattrs seem to
work:
> 
> root at nas2:/mp0/storage/backup# touch userattr
> root at nas2:/mp0/storage/backup# setfattr -n user.steffen -v washere
userattr
> # file: userattr
> user.steffen="washere"
> 
> but not for security:
> 
> root at nas2:/mp0/storage/backup# touch secattr
> root at nas2:/mp0/storage/backup# setfattr -n security.NTACL -v 1 secattr
> setfattr: secattr: Operation not permitted
> 
> (the same works on the proxmox host; the container is not privileged).
> Because of "acl_xattr:ignore system acls", I think
"security.*" fattrs
> won't be used but something like "user.samba...." or so.
> 
> NB: On file systems, permissions and ACLs do not need to work, there
> is no access to filesystem, neither host nor guest, only via Samba.
> Only the remote client (robocopy.exe) should be able to correctly copy
> the values back.
> 
>
I do not think you can do this, storing ACL's is to a certain extent 
dependant on being able to 'evaluate' them. I think that if you were to 
copy anything to a standalone server, you would have to do it as a user 
known to the standalone server and the files would then belong to that 
user i.e. you would lose the ACL's.

The only way around this, that I can think off, would be to compress the 
backup into a tarball and copy this across, whilst the tarball would end 
up belonging to your backup user, the files inside it should still have 
your ACL's.

Of course it is possible that someone will say that they have been doing 
it for years and this is how you do it ;-)

Rowland

On 1/12/23 14:54, Steffen Dettmer via samba wrote:
> I read several articles on the internet, but I fail to understand how
> ACL storage technically works. Of course in almost any case, ACL
> should not only be stored but also evaluated, and for this this Samba
> server needs to be a member of the AD domain. I think I understand
> this, but I have a different use case. I hope someone can help and
> possibly has a link or such.
ACLs are not dependent on being a domain member.

Not sure what you're aiming for as I've just skimmed your posting, but I
guess what you're looking for is the module option

        acl_xattr:security_acl_name = NAME

You need a relatively new Samba version (iirc) for this.

The security xattr namespace is not accessible from containers by 
default unless you run the container in privileged mode.

Cheers!
-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20230112/05ab2404/OpenPGP_signature.sig>