You don't understand how Samba works. smbd changes uid and gid to the given value to enforce security on filesystem access. Without a valid uid/gid list for the system that Samba is running on there's no way to do this. Other systems like Apache can do this as they never change their uid list, only running as one user.
Jeremy.

I didn't think the reply would be so fast and in the absolute way you replied.

I get your point, but I think you didn't get the point I want to expose. In fact, you didn't explain why you can't get what you pretend with the explanation. I'll try to explain harder.

First of all, an admin decision is needed: if the filesystem access will be exclusive (i.e., used only by samba) or not. In the second case, surely it's more difficult to implement, but that's not definitely the point for this bug, and where the current working methodology by using nss_ldap gets the best results.

Let's go to the first case, where the all the access by the clients is supposed to be done exclusively by samba daemons. In my case, I have the task to deploy samba on a corporate network with several hundred users, being the *only* need to login into the domain and access to the shares. No access from the local server filesystem is needed (maybe root in case of problems or backup, but nothing else). So, I can't find the problem as long as, like as winbind, and uid/gid range is reserved, that the admin should have prevented when assigning the uid/gid values in LDAP tree. The filesystem permissions could be perfectly numbers, and for finding the creator, just a simple query to the ldap db (if there isn't any caching method) is necessary. Apache doesn't do this because it works with one user only (thinking closer, apache is a bad example for the way samba works, since there's only one uid when writing, though apache can retrieve any uid when authenticating against ldap), but for instance proftpd assigns every defined uid/gid in the filesystem for the virtual user/group, so the ftp server can always provide filesystem security and return names instead of just numbers. I think that as long as samba is able to use any uid/gid for writing, the only problem is how to map that uid/gid to a name, and even apache is able to do that. I think you can't say "the only way to map a uid into a name is by the local database", which is against unix open, already working and flexible ways.

Remember: this is just an alternative auth method that provides extra value for samba, which shouldn't stop existing installations, and also helps to implement things like ldapsam:posix or ldapsam:trusted with less security headaches.

I have collected favorable opinions for this from system admins implementing samba and agree that something like this would help samba deployment a lot and reduce headaches. I think it shouldn't be too hard to develop, but that would only delay more or less time, and shouldn't be the issue to reject this bug. As a major drawback, maybe it should be necessary to rework some core mechanisms, but that's just a matter of recoding. Even if samba 4 wouldn't be able to do it, then schedule the rework for samba 5.

Anyway, your comments has a background "it's absolutely impossible to do", but I'm sure it's not impossible to do, so I please ask to leave this open some days for discussion if my above reasons can't convince you, and so let some more eyes to be able to have a different opinion from yours. It wouldn't be fair to leave this important feature closed by only one or two opinions instead of .

Feel free to submit a patch :-)

Volker

After some discussion on IRC, the concept of "virtual users" doesn't seem to be clear. It is very similar to the current idmap background: reserve a range for special users. Also, the filesystem doesn't understand names, but numbers when taking a look at permissions. If you delete a user from the system but not his files, you will the uid number he had before deletion. Also, chown and setfacl can use a numerical uid/gid to specify ownership.


Maybe one example is better:

- Current scenario: a working LDAP together with a linux OS with samba 3. The uids in /etc/passwd aren't higher than 1010. We reserve the range from 5000 on for samba users. There's a LDAP server where "user1" has an uid of 5000 and gid 5000. Also, "user2" has uid 5001 and gid 5000 (gid 5000 is mapped to "Domain Uses"). The LDAP is integrated in nsswitch (together with nss_ldap and other stuff installed and configured, not a trivial task), so "getent passwd" shows /etc/passwd + the ldap entries, including "user1" and "user2". When via samba "user1" writes to disk, the filesystem stores "5000" and gid "5000". If you perform a "ls -l" in the OS, you will see "user1" as owner and the unix groupname for gid 5000, and "user2" files with uid 5001 and gid 5000, and so on with the rest of users. These aren't virtual users and slows down the whole system, but works.

Now, to get virtual users, we would remove the ldap reference in /etc/nsswitch.conf, so the system calls through nss can't now locate users stored in LDAP. The point would be to tell samba to retrieve *the same data directly from LDAP, just like nss* used to do before removing the ldap reference. If you take a look at the filesystem with "ls -l", you will see now only the numbers, but the permissions are still active and the kernel won't complain at all, so you can still keep all as before by just using the same uid, stored in the exact very same "physical" location as before. Also, remember that samba already has all the necessary info for this: trees, credentialas, ranges, etc. So, whenever samba needs info from NSS, why not having the chance to do it on its own (i.e. act directly as ldap client)? Samba intensively acts as ldap client when retrieving some info or writing some info in LDAP, so I don't find this a problem. If you rely on NSS, why don't rely also on this, which is technically the same, maybe even faster?

What samba does later with the uid/gid is not part of this bug, and I think there should be no changes in that part because of this.

Since the last comments on IRC seem to indicate that a simple patch is easy to do, but as I understand, harder for branch release, I suggest to create an option "ldap user management", whose default is "no" (for backwards compatibility), and when set to "yes" (or true), then it would take the ldapsam settings for user management, instead of the current behaviour via system calls.

If you want me to provide more info or write some documentation about this, please let me know.

Just a question: Why is nss_ldap so bad?

Volker

Hi, Volker.

The point that I want to stand out is the concept of virtual, and using nss_ldap just opens the door for a user to become a real user, opposite to virtual, who has the door always closed.

Also, virtual databases can be taken anywhere, and since they're not tightened to the system accounts, they're not dangerous by themselves, because they're only used for just accessing own and/shared data. Windows shares are very similar to what ftp is, ie., just copy files or run some remote file in the local userspace. Also, "samba+nss ldap layer" is just one extra (duplicate) step for the master info already stored in ldap (i.e., the info could be extracted simply as any other services like postfix, apache, courier and many others do). Just instead of samba knowing about the ldap credentials by itself, go and ask the nss database, use that known information to directly query the ldap backend.

Of course, I don't mean to remove current nss_ldap integration, I'm just asking for samba to have an alternative way to perform the same operation, and IMHO, in a more secure way. I think this is would be a valuable and powerful enhancement.

Sorry, but I really fail to see how nss_ldap enabled users for which you do not have PAM configured or PAM configured in a way that it does not allow login for those users can be more secure than the Samba+LDAP(no nss_ldap) combo would be. There's plenty of ways in a Unix system to deny login for users coming in via LDAP, starting with a default shell of /bin/false over just not configuring PAM for them.

Volker

Sorry samba is built with the assumption of delegating access control to the underlying OS and using system users.

Works as designed.