samba - Feb 2017 - Windows ACL clarification for Roaming Profiles share

On Sat, 18 Feb 2017 00:28:14 +0100
Marc Muehlfeld <mmuehlfeld at samba.org> wrote:
> 
> Yes, because
> 1.) It might be necessary _locally_ on the Windows DC
>      because some _local_ services (e. g. Virus scanners,
>      etc) may access the files _locally_ _on the DC itself_.
>      However if anything on the client (the OS or a user)
>      would access the share using the SYSTEM privilege,
>      then "full control" is surely not the permission
>      you grant to the SYSTEM account to all files including
>      subfolders. :-)
What you say has some validity, but people have been known to run a
virus scanner on Linux machines, just to scan windows files.
> 2.) This page justs list a bunch of accounts without
>      explaining why it should be a requirement. Nor it
>      says that it won't work without.
You could say the same about the Samba wiki page.
> 3.) If SYSTEM would be a requirement on the profiles
>      or any other share for a Windows client, then
>      shares using POSIX ACLs would not work at all.
I fail to see why they wouldn't
> 
> If you still don't believe me, try it:
I believe it works for you without SYSTEM, but I thought that the Samba
AD DC was supposed to be compatible with a Windows DC and as such, it
should be set up in the same way.

Rowland

Am 18.02.2017 um 10:50 schrieb Rowland Penny via samba:
>> Yes, because
>> 1.) It might be necessary _locally_ on the Windows DC
>>      because some _local_ services (e. g. Virus scanners,
>>      etc) may access the files _locally_ _on the DC itself_.
>>      However if anything on the client (the OS or a user)
>>      would access the share using the SYSTEM privilege,
>>      then "full control" is surely not the permission
>>      you grant to the SYSTEM account to all files including
>>      subfolders. :-)
>
> What you say has some validity, but people have been known to run a
> virus scanner on Linux machines, just to scan windows files.
The virus scanner can use _any_ account on the local machine. If it must 
access all files, start the job as "root". Or you create a new account
that is part of the ACLs and use this one.

I would avoid using a Samba internal account for that. If Samba is down, 
NSS not configured correctly, etc. the job would fail.

However, and this is the main reason, you can't use the SYSTEM account 
in the OS. Have you tried to "su" to this account? Maybe it's
possible
with some hack after you manually edit the database and assigned a UID, 
etc., but this account appears nowhere in the user account management, 
like on Windows.



>> 2.) This page justs list a bunch of accounts without
>>      explaining why it should be a requirement. Nor it
>>      says that it won't work without.
>
> You could say the same about the Samba wiki page.
Yes I know, but I haven't rewritten the Profiles page yet.

When I rewrote the "User Home Folder" page, I omitted SYSTEM in the
list
of Windows ACLs (and of course it was never part of the POSIX ACLs in 
this guide). However, I saw no reason to explain things that I don't 
tell the user to set and what not necessary. If you follow the guide, 
you get everything you need for a fully working share.



>> 3.) If SYSTEM would be a requirement on the profiles
>>      or any other share for a Windows client, then
>>      shares using POSIX ACLs would not work at all.
>
> I fail to see why they wouldn't
If you argue that the SYSTEM account must exist in the ACLs of a profile 
share's file system, then the following shared folder would fail, 
because only root and "Domain Users" are part of the ACLs:

$ ls -la /srv/samba/profiles -d
drwxr-s--- 21 root "Domain Users" 4096 15. Feb 19:10
/srv/samba/profiles

However, it works.




>> If you still don't believe me, try it:
>
> I believe it works for you without SYSTEM, but I thought that the Samba
> AD DC was supposed to be compatible with a Windows DC and as such, it
> should be set up in the same way.
That's why it is part of the Sysvol share's file system ACLs. To be 
consistent. However, this is only to be _consistent_. It has nothing to 
do with being _compatible in this case.



Regards,
Marc

On Sat, 18 Feb 2017 12:08:01 +0100
Marc Muehlfeld <mmuehlfeld at samba.org> wrote:
> The virus scanner can use _any_ account on the local machine. If it
> must access all files, start the job as "root". Or you create a
new
> account that is part of the ACLs and use this one.
> 
> I would avoid using a Samba internal account for that. If Samba is
> down, NSS not configured correctly, etc. the job would fail.
> 
> However, and this is the main reason, you can't use the SYSTEM
> account in the OS. Have you tried to "su" to this account? Maybe
it's
> possible with some hack after you manually edit the database and
> assigned a UID, etc., but this account appears nowhere in the user
> account management, like on Windows.
You can 'map' SYSTEM on a domain member, couldn't seem to get it to
work on a DC, though I didn't try hard ;-)
> 
> 
> 
> 
> >> 2.) This page justs list a bunch of accounts without
> >>      explaining why it should be a requirement. Nor it
> >>      says that it won't work without.
> >
> > You could say the same about the Samba wiki page.
> 
> Yes I know, but I haven't rewritten the Profiles page yet.
> 
> When I rewrote the "User Home Folder" page, I omitted SYSTEM in
the
> list of Windows ACLs (and of course it was never part of the POSIX
> ACLs in this guide). However, I saw no reason to explain things that
> I don't tell the user to set and what not necessary. If you follow
> the guide, you get everything you need for a fully working share.
I think 'SYSTEM' should be mentioned, if only to say why you don't
need
it.
> 
> If you argue that the SYSTEM account must exist in the ACLs of a
> profile share's file system, then the following shared folder would
> fail, because only root and "Domain Users" are part of the ACLs:
> 
> $ ls -la /srv/samba/profiles -d
> drwxr-s--- 21 root "Domain Users" 4096 15. Feb
> 19:10 /srv/samba/profiles
> 
It appears you don't have any ACLs set there, just Unix permissions, I
have:

ls -lad /home/SAMDOM/profiles/
drwxrwx--T+ 2 root root 4096 Nov 28 12:12 /home/SAMDOM/profiles/

> That's why it is part of the Sysvol share's file system ACLs. To be
> consistent. However, this is only to be _consistent_. It has nothing
> to do with being _compatible in this case.
Not going to argue over a word, but we should be consistent about being
consistent ;-)

Rowland