samba - Jul 2016 - distributing samba users to the local systems

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

Cheers,

mathias

2016-07-12 2:10 GMT+02:00 Xen <list at xenhideout.nl>:
> I want to ask what is the most common approach, and most functional
> smallest-subset-technology approach to achieving the following.
>
>
> - a samba server is using different users for its clients and these users
> are general unix users, owning files and whatnot on the fs.
>
> - a linux system as client now wants to "import" the users from
the server
> without making them /fixed/ unix/passwd users on the local system
>
> - the users need to be imported from a kind of directory service (ldap or
> whatever) or perhaps "active directory" or whatever it might be,
and those
> extra virtual users are only valid for as long as the samba shares
> themselves are valid and accessible.
>
> Mind you, I know nothing about "active directory" or "domain
controllers"
> or what it might be. I also have very little understanding of what
> "nsswitch" is and the documentation for it and the entire system
itself
> seems to be rather arcane.
>
> It would require on the client:
> - an additional source of local users that cannot actually be logged in
> to, but only serve as user interface elements.
> Perhaps these local users would need to be mapped onto random numbers or
> something, but normally with unix extensions you see the raw numbers of the
> users on the central system (server).
>
> So either those numbers would need to be replaced by names at domain while
> crossing the link and then mapped back to new numbers on the local system,
> that has imported the names at domain, or you'd need to find a fixed
"range"
> of numbers for users that can stay fixed from system to system.
>
> I haven't even been able to get idmapping to work for NFS, it just
won't
> work. I was using a "static" file for that but the thing would
never read
> the static maps.
>
> It would require on the server:
>
> - a set of local users transformed into a directory service that clients
> can import or know about.
>
>
> Is this possible and what technologies would I need for it?
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

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

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