Messages in this thread | | | Date | Tue, 6 Jul 1999 10:01:07 +0300 | From | Matti Aarnio <> | Subject | Re: LDAP |
| |
On Tue, Jul 06, 1999 at 02:35:53AM +0000, Glen Turner wrote: > Raiden wrote: > > Any LDAP compliance on Linux Kernel? > > are any thingking about this point? > > Khimenko Victor replied: > > Huh. Where it can be used in Linux kernel ??? Why it's > > needed there ? > > LDAP is becoming the directory access mechanism adopted by > large enterprises for user registration. So LDAP support in > the Linux kernel allows people to log into Linux machines with
What *kernel* has to do with user authentication ? Have you seen *kernel* doing 'login' prompting and password analysis ? Last time around I looked, it seemed to be a user program called /bin/login ...
> the same userid, password, etc that they use for dial-in, web > server access, mainframe use, etc. Common corporate LDAP > systems come from Netscape and Novell, but there is a wide > variety of offerings.
Yes, LDAP is a directory ACCESS PROTOCOL -- one way for accessing information. That information semantics may be similar to "/etc/passwd", and its uses, but it absolutely is not limited to it.
Most people unfamiliar with the system believe LDAP to be some magic DATABASE. It isn't.
See RFC 2307: Using LDAP as a Network Information Service which shows one way to use LDAP to achieve NIS-like setup.
> There is an LDAP Pluggable Authentication Module for Linux > at: > http://www.padl.com/ > that adds LDAP support to the Linux kernel for user > authentication and, optionally, registration.
Those are *user space* modules, NOT KERNEL.
> Usual caveats about Linux's 16-bit numeric UIDs exacerbating > the hell of aligning multiple manufacturers `reserved' UID/GID > ranges apply.
Oh, you are intel user, aren't you ?
That small numeric space of UIDs is another (and certainly kernel) issue, mainly though because of lots of syscalls and pre-existing software BINARIES with 16-bit UIDs/GIDs.
In userspace glibc 2.1 (at least) has 32-bit uid_t, but kernel syscalls are still 16-bit ones.
Getting out of that requires rather massive change, which indeed might not be quite what you want. (Recompile kernel with enlarged __kernel_uid_t, recompile glibc 2.1 with matching __kernel_uid_t, THROW AWAY/RECOMPILE ALL BINARIES THAT ARE STATICALLY LINKED AND/OR OTHERWISE DON'T USE glibc 2.1.)
Implementing a new set of syscalls with enlarged passed values in value fields/whatnot is better way, and it will "only" need support in the glibc 2.1. Old binaries will still run, although strange alias effects might appear when (uid % 65536) == 0, etc..
> -- > Glen Turner Network Specialist > Email: glen.turner@adelaide.edu.au South Australia
/Matti Aarnio <matti.aarnio@sonera.fi>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |