Re: NSS Project
I was looking for followups to this thread and have searched the archives for more information without luck. I have a few questions. Has this project furthered any and where can one get the diffs / source??? Is there a website that goes in depth about the project. JOHN Following on the NSS (Name Service Switch): *Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented by Luke Mewburn. See attached patch to libc and new header file. I'm also attaching the man page for /etc/nsswitch.conf. Right now it compiles, installs, and works for some simple tests I've run. *Step Two: make getpwent, getgrent, and friends actually use the nsdispatch function. I've already started looking at the source, but am having trouble with the NIS part. Maybe someone more knowledgeable could write the NIS function. Basically we have to reduce each of the functions to a simple nsdispatch call and then implement the real functions... Here's an example from getpwent.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote: I was looking for followups to this thread and have searched the archives for more information without luck. I have a few questions. Has this project furthered any and where can one get the diffs / source??? Is there a website that goes in depth about the project. I've been very busy and seem to be the only one doing something along this line. As I said earlier, I've ported the nss stuff from NetBSD and posted some patches to the list a while back that had the nsdispatch function implemented. It was not a complete implementation since the get*ent functions in libc were not modified to use the nsdispatch function. I started to look into nsdispatch to make it dynamically load the get*ent functions using dlload (a la pam) but had a lot of work in the meantime and didn't finish the stuff. I've started looking into the code agan (yesterday) and it doesn't seem too difficult to have it dynamically load the stuff. I'll post to the list when I have code that actually does something :) regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
I was looking for followups to this thread and have searched the archives for more information without luck. I have a few questions. Has this project furthered any and where can one get the diffs / source??? Is there a website that goes in depth about the project. JOHN Following on the NSS (Name Service Switch): *Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented by Luke Mewburn. See attached patch to libc and new header file. I'm also attaching the man page for /etc/nsswitch.conf. Right now it compiles, installs, and works for some simple tests I've run. *Step Two: make getpwent, getgrent, and friends actually use the nsdispatch function. I've already started looking at the source, but am having trouble with the NIS part. Maybe someone more knowledgeable could write the NIS function. Basically we have to reduce each of the functions to a simple nsdispatch call and then implement the real functions... Here's an example from getpwent.c To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Fri, Aug 27, 1999 at 01:33:03PM -0500, John Sconiers wrote: I was looking for followups to this thread and have searched the archives for more information without luck. I have a few questions. Has this project furthered any and where can one get the diffs / source??? Is there a website that goes in depth about the project. I've been very busy and seem to be the only one doing something along this line. As I said earlier, I've ported the nss stuff from NetBSD and posted some patches to the list a while back that had the nsdispatch function implemented. It was not a complete implementation since the get*ent functions in libc were not modified to use the nsdispatch function. I started to look into nsdispatch to make it dynamically load the get*ent functions using dlload (a la pam) but had a lot of work in the meantime and didn't finish the stuff. I've started looking into the code agan (yesterday) and it doesn't seem too difficult to have it dynamically load the stuff. I'll post to the list when I have code that actually does something :) regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote:
In article [EMAIL PROTECTED],
Brian F. Feldman [EMAIL PROTECTED] wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have them in libc, for instance...
The versions in libc are just stubs. Take a look at
"src/lib/libc/gen/dlfcn.c". The implementations are in the dynamic
linker.
Yes. I said "have them" as in "we could", not "we do have them in libc..."
One option I don't think anyone's brought up: why don't we _just_
have ld-elf.so.1 in the root, but not libraries? That way, we
don't bloat root excessively, but we can let people depend on
being able to build -static/-Bstatic binaries that make everything
static except the rtld? And modify gcc/ld to have static link with
the rtld, so we have the benefit of those calls, can have static
binaries still, and be able to depend on having an rtld (even for
single-user mode.)
I think you have some misconceptions about how it all fits together.
Executables aren't "linked with" the dynamic linker. It's a
separate shared object that is loaded directly by the kernel. It
gets control before the main executable gets control. Look at
"src/sys/kern/imgact_elf.c" and at the dynamic linker.
I suppose I do have some misconceptions. I'll look at the "FreeBSD" ELF
image activator. I know how ld-elf gets control first, and calls .init
things, etc. But:
{"/usr/src/contrib/egcs"}$ grep -R ld-elf .
./gcc/config/alpha/freebsd.h: %{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd.h:%{!dynamic-linker: -dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd-elf.h:%{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
What should that tell me exactly?
Also, programs that are linked (at "ld" time) with dynamic libraries
are different from programs that are linked with static libraries.
I.e., "ld" does very different things in the two cases. You can't
take a statically-linked program and suddenly decide to treat it as
dynamically-linked at runtime. It's too late at that point.
Of course, but you can have a pseudo-static binary, one that only
needs ld-elf.so.1 but not libc, etc.
Finally, shared "libraries" aren't really libraries at all in the
traditional sense. They're monolithic whereas traditional archive
libraries are made up of separate object files which are subsetted by
the linker.
Mm-hmm. ld -Bshareable as opposed to ar rc.
To really understand the issues I think it's necessary to read through
the dynamic linker sources and understand what it's doing. There used
to be books that described how it all worked (Prentice-Hall "System V
Application Binary Interface"), but as far as I know they're out of
print now.
I just think we're not seeing eye to eye.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote: Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I know exactly how an ar archive is made of all the non-PIC .o files and a ranlib works. I know what happens when ld puts together position- independent-code (which is position-independent because it uses the GOT) and generates a shared library. I know how GCC only includes the .o files from an ar library archive which it needs and nothing more. I know that the dl* functions in libc itself are just stubs. All I don't know is why we can't load ld-elf.so.1 for static executables as well as "dynamic" ones. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. I was asking because I wanted to be referred to where I could find where these were discussed. I'm not going to wade through a search that I don't even have a hint on what to look for. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
Peter Jeremy wrote: I apologize if I gave anyone the impression that you couldn't build statically linked executables with libpam. Sorry I was so prickly about it. I recall having a similar static-vs-dynamic discussion with you a couple of years ago. Yow, your memory is better than mine. Premature senility is a sad, sad thing. :-} My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). I generally agree, except I feel that when there are cases where we can do useful things which rely on dynamic linking, we shouldn't let static linking hold us back. Plenty of people disagree with me, though. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote: My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). I generally agree, except I feel that when there are cases where we can do useful things which rely on dynamic linking, we shouldn't let static linking hold us back. Plenty of people disagree with me, though. Mind pointing me to the technical reason why (I'm sure you've explained it before) we can't use the dl* calls in any way without linking against ld-elf.so.1? I mean, have them in libc, for instance... One option I don't think anyone's brought up: why don't we _just_ have ld-elf.so.1 in the root, but not libraries? That way, we don't bloat root excessively, but we can let people depend on being able to build -static/-Bstatic binaries that make everything static except the rtld? And modify gcc/ld to have static link with the rtld, so we have the benefit of those calls, can have static binaries still, and be able to depend on having an rtld (even for single-user mode.) John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net, Brian F. Feldman gr...@freebsd.org wrote: Mind pointing me to the technical reason why (I'm sure you've explained it before) we can't use the dl* calls in any way without linking against ld-elf.so.1? I mean, have them in libc, for instance... The versions in libc are just stubs. Take a look at src/lib/libc/gen/dlfcn.c. The implementations are in the dynamic linker. One option I don't think anyone's brought up: why don't we _just_ have ld-elf.so.1 in the root, but not libraries? That way, we don't bloat root excessively, but we can let people depend on being able to build -static/-Bstatic binaries that make everything static except the rtld? And modify gcc/ld to have static link with the rtld, so we have the benefit of those calls, can have static binaries still, and be able to depend on having an rtld (even for single-user mode.) I think you have some misconceptions about how it all fits together. Executables aren't linked with the dynamic linker. It's a separate shared object that is loaded directly by the kernel. It gets control before the main executable gets control. Look at src/sys/kern/imgact_elf.c and at the dynamic linker. Also, programs that are linked (at ld time) with dynamic libraries are different from programs that are linked with static libraries. I.e., ld does very different things in the two cases. You can't take a statically-linked program and suddenly decide to treat it as dynamically-linked at runtime. It's too late at that point. Finally, shared libraries aren't really libraries at all in the traditional sense. They're monolithic whereas traditional archive libraries are made up of separate object files which are subsetted by the linker. To really understand the issues I think it's necessary to read through the dynamic linker sources and understand what it's doing. There used to be books that described how it all worked (Prentice-Hall System V Application Binary Interface), but as far as I know they're out of print now. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote:
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have them in libc, for instance...
The versions in libc are just stubs. Take a look at
src/lib/libc/gen/dlfcn.c. The implementations are in the dynamic
linker.
Yes. I said have them as in we could, not we do have them in libc...
One option I don't think anyone's brought up: why don't we _just_
have ld-elf.so.1 in the root, but not libraries? That way, we
don't bloat root excessively, but we can let people depend on
being able to build -static/-Bstatic binaries that make everything
static except the rtld? And modify gcc/ld to have static link with
the rtld, so we have the benefit of those calls, can have static
binaries still, and be able to depend on having an rtld (even for
single-user mode.)
I think you have some misconceptions about how it all fits together.
Executables aren't linked with the dynamic linker. It's a
separate shared object that is loaded directly by the kernel. It
gets control before the main executable gets control. Look at
src/sys/kern/imgact_elf.c and at the dynamic linker.
I suppose I do have some misconceptions. I'll look at the FreeBSD ELF
image activator. I know how ld-elf gets control first, and calls .init
things, etc. But:
{/usr/src/contrib/egcs}$ grep -R ld-elf .
./gcc/config/alpha/freebsd.h: %{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd.h:%{!dynamic-linker: -dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd-elf.h:%{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
What should that tell me exactly?
Also, programs that are linked (at ld time) with dynamic libraries
are different from programs that are linked with static libraries.
I.e., ld does very different things in the two cases. You can't
take a statically-linked program and suddenly decide to treat it as
dynamically-linked at runtime. It's too late at that point.
Of course, but you can have a pseudo-static binary, one that only
needs ld-elf.so.1 but not libc, etc.
Finally, shared libraries aren't really libraries at all in the
traditional sense. They're monolithic whereas traditional archive
libraries are made up of separate object files which are subsetted by
the linker.
Mm-hmm. ld -Bshareable as opposed to ar rc.
To really understand the issues I think it's necessary to read through
the dynamic linker sources and understand what it's doing. There used
to be books that described how it all worked (Prentice-Hall System V
Application Binary Interface), but as far as I know they're out of
print now.
I just think we're not seeing eye to eye.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
No matter how cynical I get, I just can't keep up.-- Nora Ephron
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote: Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I know exactly how an ar archive is made of all the non-PIC .o files and a ranlib works. I know what happens when ld puts together position- independent-code (which is position-independent because it uses the GOT) and generates a shared library. I know how GCC only includes the .o files from an ar library archive which it needs and nothing more. I know that the dl* functions in libc itself are just stubs. All I don't know is why we can't load ld-elf.so.1 for static executables as well as dynamic ones. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. I was asking because I wanted to be referred to where I could find where these were discussed. I'm not going to wade through a search that I don't even have a hint on what to look for. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Peter Jeremy [EMAIL PROTECTED] writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
Assar Westerlund [EMAIL PROTECTED] wrote: Peter Jeremy [EMAIL PROTECTED] writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? Quite probably PAM has the same problem. I haven't bumped into it with PAM, so I can't be sure. I definitely wouldn't like to get into the situation where init can fail to load (or be unable to validate the single-user password for a secure console) because the appropriate encryption library is on a partition that isn't mounted yet (or has been corrupted somehow). The idea of being able to dynamically add new password encrytion schemes (PAM) or database access methods (NSS) is generally good. The problems appear when you try to marry these schemes with the system security and initialisation/recovery tools (which need to rely on and trust a minimal subset of the system). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
John Polstra [EMAIL PROTECTED] wrote: Peter Jeremy [EMAIL PROTECTED] wrote: Assar Westerlund [EMAIL PROTECTED] wrote: Peter Jeremy [EMAIL PROTECTED] writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? Quite probably PAM has the same problem. I haven't bumped into it with PAM, so I can't be sure. When you're not sure, it's really best to find out or keep quiet on the mailing list. Maybe I should have worded it differently: In order to build statically linked applications, both PAM and NSS have to solve a similar problem. If it can or has been solved for PAM (which I wasn't sure about), the same (or a very similar) solution will work for NSS. PAM doesn't work in statically-linked executables" -- which is false. It works fine. I apologize if I gave anyone the impression that you couldn't build statically linked executables with libpam. It is implemented using a linker set approach which you are encouraged to investigate in the sources. A similar approach should work for NSS, though a case could probably be made for having statically linking mean `only rely on local files'. the situation where init can fail to load ... because the appropriate encryption library is on a partition that isn't mounted yet I should also point out that init doesn't use PAM at present, so this problem can't occur. (The downside if that if the root password doesn't use the default encryption method, init won't be able to validate it). But nothing would be qualitatively different if we went to an all-dynamic scheme (which I hope we will do some day). I recall having a similar static-vs-dynamic discussion with you a couple of years ago. My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
hi, there!
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
*Step One: I ported the NetBSD implementation of nsdispatch(3) as
implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
*Step Two: make getpwent, getgrent, and friends actually use the nsdispatch
function. I've already started looking at the source, but am having trouble
with the NIS part. Maybe someone more knowledgeable could write the NIS
function.
Basically we have to reduce each of the functions to a simple nsdispatch
call and then implement the real functions... Here's an example from
getpwent.c
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
r = nsdispatch(NULL, dtab, NSDB_PASSWD, getpwent, compatsrc,
_PW_KEYBYNUM);
if (r != NS_SUCCESS)
return (struct passwd *)NULL;
return _pw_passwd;
}
The we have to implement _local_getpw, _dns_getpw, _nis_getpw,
and _compat_getpwent and make them behave as expected.
NetBSD seems to support having the passwd database on DNS using something
called HESIOD (I hadn't heard about it before). I don't think FreeBSD
*Step Three: Implement _ldap_getpw :)
pam/nss ldap modules are already available (http://www.padl.com)
i think we should implement NSS in that way so we need not recompile if we
want to add third-party nss module. Also compatibility with Solaris is
desirable.
/fjoe
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Wed, 4 Aug 1999, Peter Jeremy wrote: Oscar Bonilla oboni...@fisicc-ufm.edu wrote: If anyone has any comments, suggestions, etc. I would appreciate it. Overall, I like the idea of NSS. But, having worked on Solaris 2.x for some time, we need to avoid some of the blunders Sun made: The biggest problem with Sun's NSS implementation is that it's no longer possible to statically link an application that uses any of the get...byname() functions that have NSS backends. We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. well you could just link in the shared nss object statically into it...? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Peter Jeremy jere...@gsmx07.alcatel.com.au writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Assar Westerlund as...@sics.se wrote: Peter Jeremy jere...@gsmx07.alcatel.com.au writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? Quite probably PAM has the same problem. I haven't bumped into it with PAM, so I can't be sure. I definitely wouldn't like to get into the situation where init can fail to load (or be unable to validate the single-user password for a secure console) because the appropriate encryption library is on a partition that isn't mounted yet (or has been corrupted somehow). The idea of being able to dynamically add new password encrytion schemes (PAM) or database access methods (NSS) is generally good. The problems appear when you try to marry these schemes with the system security and initialisation/recovery tools (which need to rely on and trust a minimal subset of the system). Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project update
On Wed, 4 Aug 1999, Oscar Bonilla wrote: [skip] 2. Make the C library nsdispatch aware. The dtab[] array will be filled dynamicaly from the contents of /etc/nsswitch.conf. I'm still not sure if this has to be done whithin the C library or if nsdispatch should fill the dtab[] array itself and not relay on the caller (i.e. drop the dtab[] parameter). It seems to me at this point that the easiest approach is to have nsdispatch fill the dtab array itself. dtab[] array *should* be filled in nsdispatch, otherwise how will you keep me from writing an empty get*() function ? [skip] Someone mentioned that we should still be able to produce statically linked binaries for things like /stand and /sbin. I suggest making the nsdispatch (or get* functions) revert to files if everything else fails (not the modules themselves, but the loading of the modules). How does this sound? Sounds reasonable. If functions that works with local files compiled statically we also not loose perfomance with plain setup. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
In article 99aug5.074611est.40...@border.alcanet.com.au, Peter Jeremy jere...@gsmx07.alcatel.com.au wrote: Assar Westerlund as...@sics.se wrote: Peter Jeremy jere...@gsmx07.alcatel.com.au writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? Quite probably PAM has the same problem. I haven't bumped into it with PAM, so I can't be sure. When you're not sure, it's really best to find out or keep quiet on the mailing list. As it is, you've just created a dozen or so new people all over the world who will go around saying, Hmm, I seem to remember reading that PAM doesn't work in statically-linked executables -- which is false. It works fine. It is implemented using a linker set approach which you are encouraged to investigate in the sources. the situation where init can fail to load (or be unable to validate the single-user password for a secure console) because the appropriate encryption library is on a partition that isn't mounted yet If that happened, it would have to be considered a severe design error. (or has been corrupted somehow). Many things can get corrupted to make the system unrecoverable. For example: the kernel, init itself, entries in the /dev directory, and various combinations of cp, fsck, newfs, restore, ... The idea of being able to dynamically add new password encrytion schemes (PAM) or database access methods (NSS) is generally good. The problems appear when you try to marry these schemes with the system security and initialisation/recovery tools (which need to rely on and trust a minimal subset of the system). Well, dynamic linking is here to stay, and that enlarges the scope of minimal subset somewhat. But nothing would be qualitatively different if we went to an all-dynamic scheme (which I hope we will do some day). In any case, your system has to be working to a certain degree to be recovered, or else you have to use external media such as the fixit disk. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
John Polstra j...@polstra.com wrote: Peter Jeremy jere...@gsmx07.alcatel.com.au wrote: Assar Westerlund as...@sics.se wrote: Peter Jeremy jere...@gsmx07.alcatel.com.au writes: We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Isn't that the same problem as with PAM? Quite probably PAM has the same problem. I haven't bumped into it with PAM, so I can't be sure. When you're not sure, it's really best to find out or keep quiet on the mailing list. Maybe I should have worded it differently: In order to build statically linked applications, both PAM and NSS have to solve a similar problem. If it can or has been solved for PAM (which I wasn't sure about), the same (or a very similar) solution will work for NSS. PAM doesn't work in statically-linked executables -- which is false. It works fine. I apologize if I gave anyone the impression that you couldn't build statically linked executables with libpam. It is implemented using a linker set approach which you are encouraged to investigate in the sources. A similar approach should work for NSS, though a case could probably be made for having statically linking mean `only rely on local files'. the situation where init can fail to load ... because the appropriate encryption library is on a partition that isn't mounted yet I should also point out that init doesn't use PAM at present, so this problem can't occur. (The downside if that if the root password doesn't use the default encryption method, init won't be able to validate it). But nothing would be qualitatively different if we went to an all-dynamic scheme (which I hope we will do some day). I recall having a similar static-vs-dynamic discussion with you a couple of years ago. My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
Great. I haven't alnalyse all of the code but this thing looks
a little bit limited:
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
May be I'm totally wrong, but dtab[] array can be constructed (or
extended) dynamically, based on configuration file and _*_getpw()
functions can be placed in shared libraries (just like PAM modules). In
this case it is possible to extend NSS space without disturbing libc code.
--
Boris Popov
http://www.butya.kz/~bp/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
hi, there!
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
*Step One: I ported the NetBSD implementation of nsdispatch(3) as implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
*Step Two: make getpwent, getgrent, and friends actually use the nsdispatch
function. I've already started looking at the source, but am having trouble
with the NIS part. Maybe someone more knowledgeable could write the NIS
function.
Basically we have to reduce each of the functions to a simple nsdispatch
call and then implement the real functions... Here's an example from
getpwent.c
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
r = nsdispatch(NULL, dtab, NSDB_PASSWD, "getpwent", compatsrc,
_PW_KEYBYNUM);
if (r != NS_SUCCESS)
return (struct passwd *)NULL;
return _pw_passwd;
}
The we have to implement _local_getpw, _dns_getpw, _nis_getpw,
and _compat_getpwent and make them behave as expected.
NetBSD seems to support having the passwd database on DNS using something
called HESIOD (I hadn't heard about it before). I don't think FreeBSD
*Step Three: Implement _ldap_getpw :)
pam/nss ldap modules are already available (http://www.padl.com)
i think we should implement NSS in that way so we need not recompile if we
want to add third-party nss module. Also compatibility with Solaris is
desirable.
/fjoe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Tue, 3 Aug 1999, Oscar Bonilla wrote:
Following on the NSS (Name Service Switch):
*Step One: I ported the NetBSD implementation of nsdispatch(3) as
implemented
by Luke Mewburn. See attached patch to libc and new header file. I'm also
attaching the man page for /etc/nsswitch.conf. Right now it compiles,
installs, and works for some simple tests I've run.
Great. I haven't alnalyse all of the code but this thing looks
a little bit limited:
/* Basically we reduce getpwent to a simple nsdispatch call */
struct passwd *
getpwent()
{
int r;
static const ns_dtab dtab[] = {
NS_FILES_CB(_local_getpw, NULL)
NS_DNS_CB(_dns_getpw, NULL)
NS_NIS_CB(_nis_getpw, NULL)
NS_COMPAT_CB(_compat_getpwent, NULL)
{ 0 }
};
May be I'm totally wrong, but dtab[] array can be constructed (or
extended) dynamically, based on configuration file and _*_getpw()
functions can be placed in shared libraries (just like PAM modules). In
this case it is possible to extend NSS space without disturbing libc code.
--
Boris Popov
http://www.butya.kz/~bp/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Oscar Bonilla oboni...@fisicc-ufm.edu wrote: If anyone has any comments, suggestions, etc. I would appreciate it. Overall, I like the idea of NSS. But, having worked on Solaris 2.x for some time, we need to avoid some of the blunders Sun made: The biggest problem with Sun's NSS implementation is that it's no longer possible to statically link an application that uses any of the get...byname() functions that have NSS backends. We need to be able to build an application that has no dynamically loaded code for recovery purposes (/stand and /sbin) as well as for security. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
