Re: LDAP

Matti Aarnio (matti.aarnio@sonera.fi)
Tue, 6 Jul 1999 10:01:07 +0300


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/