mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ron Van Dam" <rvandam@liwave.com>
To: "'Frank Schneider'" <SPATZ1@t-online.de>
Cc: <linux-kernel@vger.kernel.org>
Subject: RE: FW: OT: Integrating Directory Services for Linux
Date: Sun, 9 Sep 2001 20:27:21 -0400	[thread overview]
Message-ID: <001501c1398f$5bb85c40$1f0201c0@w2k001> (raw)
In-Reply-To: <3B9BCF6C.3BFC9466@t-online.de>


Frank Schneider:
>>1.) Why add an extra-DS-System to the existing ones ?
>>We have OpenLDAP, NDS (going down), ADS (going up, pushed by MS) and
>>NIS+ out there, plus things like X.500 or how they are called. Currently
>>Linux can work with most of them except ADS, AFAIK (better or worse with
>>some, but it can)
>>Why re-invent the wheel a 4th or even 5th time ?

 Using ADS or NDS is not a good solution, because in my opinion, it would be
dependent on a another OS. I would rather have the DS maintained on a
OpenSource OS. NIS+ is basically obsolete. OpenLDAP could be turned into a
workable solution, but there is no "consistent" bridge between OpenLDAP and
Linux. For instance if you want to manager user accounts with it you need
PAM, and unfortunately PAM isn't compatible with a lot of userland
applications and services.

In my opinion, I don't see any way for directory services to become a fully
enabled tool without full support from all of the major Linux development
groups. I believe its going require a lot of effort to to make it a reality.
I don't think DS will work unless there some standard for DS established by
the core linux development groups. Another words, what I would like have is
the framework for a standard for implemeting DS for Linux.

>> I think these DS-Systems are really a part of userland, and the
>>kernel itself should never mess around with high-level-security issues
>>like Access Controll Lists or such things...this is the job of
>>userlandtools.

Agreed, the database any other tools can be done in userland and should be.
I started this discussion to see if anyone out there considers DS important
for Linux growth.  I am not sugguesting that this should be in the kernel.
Just some sort of directory system that can manage configurations of a large
number of linux boxes.

However, I don't see how you can manage permissions to kernel function calls
with out some kernel support. Depending on what level of functionally is
included, there may be a need access database information during boot-up,
before userland processes can be started. If you managing kernel functions
calls for userland access, how can you tell if the process has permissions
unless some functionally is built-in the kernel? Think of a directory
service operating more like a file system than a database.

>>The problem i see, if you force these things into the kernel, you will
>>get a significant performance impact, because if you start to do
>>(perhaps complicated) securitychecks *everytime* before calling a single
>>function, you will loose time...and performance is one of the points
>>where linux is ahead of other OSes, IMHO.

You're probably right. Perhaps groups of function calls could be grouped and
other methods could be implemented to manage overhead, or shouldn't even be
considered. However, I believe  here is already some limited support for
this (RSBAC http://www.rsbac.org) and CAPs. Its just not supported in a
directory service.

>>3.) To the idea of a "linux-registry":
>>I do not like this, UNIX lives now 30 years with /etc and human-readable
>>configfiles and without a "database", and i think its a good compromise
>>between usability and "keep-it-simple".
>>And it works.

The Windows Registry isn't anything like what I am suggesting. The Windows
Registry isn't really even a database, is more or less an open draw, shoved
full of  bits and pieces of information everywhere. The Windows registry is
a lot like a /etc directory in non-human readable form. Every Windows box
has its own registry, just like every Unix box has a /etc directory. Think
of a directory service of more than a simple database and more like a shared
file system where you can access configuration information on any box from
any box you choose.

How would you manage 1000 or 10,000 desktop boxes each with their own /etc
directory?  Imagine your supporting several hundred or even several thousand
unix boxes, and you need to apply a standard change to all of them. Lets
also assume your not getting paid by the hour, or you need to get the change
done in just a hour or two. Would you trust a running a script on a
/etc/*.conf file to apply a change on your boxes? I suppose if you really
like to torture yourself, you could modify each of those files by hand,
ouch!

Thanks for the response.
Ron


  reply	other threads:[~2001-09-10  0:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-09 18:45 Ron Van Dam
2001-09-09 20:22 ` Frank Schneider
2001-09-10  0:27   ` Ron Van Dam [this message]
2001-09-10  1:04     ` Alicia Whisnant
2001-09-10  1:32     ` Alicia Whisnant
2001-09-10 11:50       ` Ron Van Dam
2001-09-13 20:10         ` Nils Philippsen
2001-09-10  9:35     ` Frank Schneider
2001-09-10 21:27       ` Horst von Brand
2001-09-11  7:41   ` Albert D. Cahalan
     [not found] <01Sep10.181449edt.63201@gpu.utcc.utoronto.ca>
2001-09-11  1:20 ` Ron Van Dam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001501c1398f$5bb85c40$1f0201c0@w2k001' \
    --to=rvandam@liwave.com \
    --cc=SPATZ1@t-online.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®