[Samba] distributing samba users to the local systems

Wed Jul 13 09:42:22 UTC 2016

I haven't yet fully read your mail, still trying to understand.

Anyway all that I read is about complexity of using several users
databases. Why not use only one user database? AD is a user database, can
be used on all these systems, can be used in conjunction with Samba... All
user names, UIDs and GIDs would be into the same DB, they would be coherent
(if you don't mess up your DB obviously ^^) and that could simplify
stuffs...

The only things which could be an issue is about clients behind a VPN (you
mentioned that techno at some point).
If this VPN is about to merge some networks, if it is permanent, these
clients would be able to access permanently AD DC and all things are easy.
If this VPN is multiple and started by each and every client randomly (e.g:
VPN for laptops accessing company's LAN from home) and these clients are
joined to AD, they will have to use credentials caching mechanism, which is
including in most of tools (from Linux or Windows) to connect on AD
domains, so there should be not too much difficulty to also have VPN
clients joined to your AD.

Now if clients are from different companies and have already one (by
company) dedicated domain, you will have an issue: you start with a real
need to deal with all these user sources...

Once user DB sources issue would be simplified you will have only to manage
others points:
- users can't connect on certain systems -> dealing with user's shell
(/bin/false, [/usr]/sbin/nologin..) or with access module
(/etc/security/access.conf)
- users are valid only as long as their shares are existing -> some script
to activate / deactivate them from AD when share is removed would do.
Whatever is the way you chose to deactivate them.

That was just morning's idea, back to read.

2016-07-13 1:05 GMT+02:00 Xen <list at xenhideout.nl>:

> 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
> ).
>