Hi!
On Sat, Oct 15, 2005 at 08:40:59AM +0200, Christian Perrier wrote:
> > No, this is NSS/libc guys' problem in first place, then
> > ours (with Tomasz).
...
> From the above, I understand that this bug should be reassigned to
> "passwd,glibc".
Yes, we should have 2 bugs one depending on another.
For example, in terms of bugzilla (I think you know its
design) -- let's call a bug for libc6 as bug1 and a bug
for passwd as bug2, then bug1 should be marked as a bug
that _blocks_ progress of bug2.
This means that without necessary changes to libc we
can't implement the features requested.
> So, we need to describe to the glibc maintainers what we are talking
> about.
>
> Can you please summarize this?
Yes, it's quite easy but lengthy description, that's
why I didn't do it before -- my laziness is the reason.
OK, here I go:
1. prerequisites:
1a) `info libc Name Service Switch`
1b) `info libc NSS` (point to consider is
"services to _access_ the databases")
1g) `info libc Group Database` (point to consider is
"how to _search_ and _scan_ the database" (R/O),
i.e. no mention of how to _change_ (R/W) the
database)
1w) `info libc Writing a User Entry` (point to
consider is the only W interface for "passwd" in
NSS:
int putpwent (const struct passwd *P, FILE *STREAM)
here we see that:
* an entry is written to file, not to the
"passwd" _database_
* citing: "This function exists for compatibility
with SVID. We recommend that you avoid using it"
1h) /usr/include/pwd.h, /usr/include/shadow.h
look into these just to confirm the
abovementioned points.
2. problems:
Basically, there's exactly one problem -- NSS
services are unidirectional, i.e. R/O, while for
updating Full Name, login shell, group members list
etc. a bidirectional (R/W) interface is required.
3. proposals:
3a) provide services for modifying the databases, at
least for "passwd", "group", "shadow" and
"gshadow" ones, as this is the most wanted
feature ATM
3b) provide underlying interface for NSS modules in
order for them to support modifications of their
respective data sources (files/NIS, LDAP, DNS
etc.)
Of course, NSS is just a layer above these
modules, so it can't add any functionality that
is not implemented or absent in modules. I.e. an
extension of the API (in fact, just a naming
conventions AFAIU -- right?) _between_ NSS and
NSS modules is required for (3a) to work.
P.S. at first I too was surprised that there's no R/W
NSS API at all in existance despite its obvious likely
usefullness.
Then I remembered history of the Hurd and think that
the current state of the matter is no big surprise,
given voluntarily nature of GNU libc development and
absense of _demand_ from major players like Sun, IBM
or even RH, SuSE etc.
P.P.S. all the story of the bug is just a sequence of
obvious misasumptions.
--
WBR,
xrgtn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
