[Samba] distributing samba users to the local systems

[Xen]

mathias dufresne schreef op 12-07-2016 13:39:
> Hi,
> 
> Let me try to re-formulate, please tell me if I'm wrong.
> 
> You have a bunch of users declared locally in /etc/passwd or something
> like that on one system.
> 
> Now you would like to have another system using this users list with
> Samba.
> You also want these users to be valid only as long as the share exist.
> You don't want these users to be able to connect on system(s).
> 
> If I'm right, that sounds possible and not too complex to achieve,
> with a minimum knowledge of UNIX systems. We can discuss about that
> once I know if my understanding of your request was good enough ;)


Hi Mathias,

your summary is correct.

At this point I activated some LDAP server on the device, that my local 
host(s) can now use to read users and group IDs so they are capable of 
"showing a username/groupname" for IDs that are not in /etc/passwd, 
since the samba mount does not do any mapping.

I just installed libnss-ldap, but not even libpam-ldap. All that was 
necessary was to configure /etc/ldap.conf and /etc/nsswitch.conf and it 
was already working.

The users on the local hosts are not getting prefixed with @domain.tld 
as they are on that server in its default config, so it also shows up 
pretty nicely in the shell (not sure what GUI actually shows user ids).

But I have to duplicate my users onto LDAP for that. In fact, at this 
point those new users are only used for some uid/gid mount from other 
systems.

What happens currently is that some user, e.g. john, connects through 
the regular user account to the server, and the server is aware of this 
(VPN). That user ID is then used to construct an LDAP user ID of the 
same name, and this is then used to mount a share FROM that user to the 
server. Not as a login credential (that is just guest) but as a 
uid=/gid= designation.

This is because as I said in my other post, the mount.cifs won't 
actually work with unix option. Mounts from the client to the server can 
use unix just fine, but mounts from the server to clients have to use 
nounix.

So the mounts from the clients (I mean the mounts shared by the clients 
now) I can only mount using no-unix-extensions and uid=/gid=, which 
means I have to give them a defined user. Since I have to do that 
anyway, I am currently giving them LDAP users since those definitely 
won't exist on the other clients.

So the shares originating from the server that DO use unix extensions 
now have LDAP users attached to all of the files.

This in turn is resolved by the clients using LDAP in 
/etc/nsswitch.conf. The only thing I haven't been able to do yet is:

- meaningfully add my local user (main user) to one of those groups such 
that he obtains write permission on some of the files.

See, since there is no idMapping going on, all the files now have alien 
specs and only root can write them.

That is not determined by the server (samba) but simply by the unix 
permissions on my local host.

The only way to fix that is to force uid, but I don't want that or I 
lose the information of file ownership.

However I also don't want to add my user to every group. The problem I 
have is that unix does not support groups within groups, ie. there is no 
group hierarchy.

Let's say I am a toad and I want write access to the frogs group. But I 
don't want to become member of frogs myself; I don't want to become a 
frog. How can I have write access locally?

The only thing I know what to do is using setfacl, but the server 
resists that.

Besides, it would have no bearing on the local system unless they were 
posix acl lists that were transmitted back. On the server I can create 
finegrained permissions but they are not transmitted ... actually they 
are, based on my logged in user.

If my user on the server is part of group "backup" and I set permissions 
for backup:

synoacltool -add hoho group:backup:allow:rwx:fd--

Then even though the group owner for file "hoho" is something else, I 
now get personalized "other" flags since my user is neither owner nor in 
the main group, and my local permissions become:

-------rw- 1 1031 65538 21 jul 12 21:16 hoho

Of course this means every user on my system will have write access 
unless I block access to the directory.

The server doesn't have pam_group and pam_exec so I may need to compile 
both.

There is no way for me to add local users to the LDAP groups.

Then order to have those permissions I need to create an equivalent LDAP 
user and log into samba using that.

However when I do so it gives preference to the local user and 
disregards the LDAP suffix. But when I add the LDAP suffix as the 
domain, it does work.

And that works. I log in as the LDAP user on samba instead of local user 
on samba system, and my local user now has:

-------rwx 1 1031 65538 21 jul 12 21:16 hoho

Except that it doesn't work. Locally even though it says rwx for "other" 
I cannot even open the file; apparently denied by the server. On the 
server this same user however does have the appropriate rights.

Whereas the non-LDAP user doesn't (as per design).

So the appropriate permissions are now transferred to the client, but 
they don't take affect when trying to be used.

At least; not for this particular file. Permissions work fine without 
these "custom" Synology ACLs, but then there is no way to add a group to 
a group.

I have no clue why I would be able to write on the filesystem but not to 
samba.

That when Samba writes on my behalve, it is denied.

I guess it checks permissions before becoming my user to see it though 
my eyes? These Syno ACLS are shifty. Hmm..


** my current problem is that samba denies me write access to a file I 
have write access to on a share I have write access to **.

My second problem is a Linux/Unix thing. Which is that I need to add 
myself to every group, to have write access to every file. I might just 
as well give them 777 and then defend the access paths instead, and be 
done with it. I am just worried there is no good way to prevent deletion 
by random users, but I'll just the sticky bit for that.

Unix permissions are just about as primitive as coming up with a fork 
with 3 prongs and then thinking you've created a masterful design no one 
can beat.

And the most obvious thing: hierarchy, doesn't even exist.

But then, the group is hardly used in the Unix world. 99% of file are 
owned by root:root, you may say that the Unix model is to have root and 
a general no-permission user, and nothing else.

The only things that ever have dedicated users/groups are daemons and 
services, that do so to have reduced capability during normal operation 
(but that are started as root regardless). And there are a few files in 
/dev, that's about it.

The state of affairs is so primitive that every good idea needs a vast 
amount of time to really develop. And in the end most successful designs 
do not even impede on the Linux model, but create their own user 
databases and interaction because they focus on web-services and the 
like. The solution to the Unix permissions is to not use it ;-).






So currently for me:

- I can use "factory default" LDAP to manually create a copy of each 
user
- I now have "virtual" users I use only to map samba shares to (by way 
of uid/gid)
- My server won't function as a client with unix extensions enabled, 
even to unix servers (samba).
- The virtual users can be imported on the clients by way of LDAP and 
for no other reason than to give names to numbers
- I installed nscd because LDAP lookup was really slow, and unreliable 
really.
- Everything I export from the server I will need to do with virtual 
users so that they are correctly displayed on the clients
- Client GUIs do not even really display any user:group information.

- Giving detailed enough permissions to public shares and public files, 
is a challenge. It's easy to make everything read-only for most. It is 
harder to give people upload permission but not modify or delete 
permission.  (Well covered in [1]). But there is not really a solution 
other than the sticky bit.

But mostly hierarchical groups are missing from Unix. It would be 
extremely trivial to implement too.

I think I can work with what I have now. It's a shame the Synology ACLs 
do not actually work with this Linux client (when accessed through 
Samba).

I wonder why that is. I wonder if Samba /cannot write/ or /thinks it 
cannot write/ (or read).






[1] 
https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/AccessControls.html).