porting PAM
invad...@flexcheck.net
I am still fairly new to C, but I thought a good place to start
contributing to OpenBSD would be to port existing modules. I understand
that PAM has not been ported to OpenBSD yet, but it has been ported to
NetBSD so that could be a good start. (atleast it's not linux -> bsd)
Anyways, i've been reading over some of the pages in section 9 of the
manual, but I don't see anything about programming modules. I've never
written a module for an OS before, So I was just wondering if someone
could point me in the direction of some good reading material.
Thanks.
Dries Schellekens
There is no need to port PAM to OpenBSD, because OpenBSD uses the BSD
Authentication framework (originally developed by BSDI).
Search the net for a comparison between BSD auth and PAM. e.g.
http://mail-index.netbsd.org/tech-userlevel/2001/06/26/0000.html
Cheers,
Dries
--
Dries Schellekens
email: gwyl...@ulyssis.org
sven_d...@gmx.de
> Hello,
>
Hi,
> [...]
> Anyways, i've been reading over some of the pages in section 9 of the
> manual, but I don't see anything about programming modules. I've never
> written a module for an OS before, So I was just wondering if someone
> could point me in the direction of some good reading material.
This article is a bit dated, but it should give you an idea of what's
going on.
http://deadly.org/article.php3?sid=20010812210650
Sven
--
You are not expected to understand this.
- Dennis Ritchie (Unix 6th Edition)
sven_d...@gmx.de
> > On Tue, 27 May 2003 invad...@flexcheck.net wrote:
> >
[...]
> > http://deadly.org/article.php3?sid=20010812210650
[...]
>
> Thanks. That is an excellent article. This is a little unrelated to my
> initial post, but I have a question about C in general. I've seen function
> definitions like this a lot: int syscall(int, char *)
>
> I don't really understand how function prototypes can get away with only
> giving the data type and not a name for it's arguments. How are these
> referenced from within the function?
If your question refers to the article: Don't worry! The artist just
wanted to show us how the new system call looks like in userland.
The point is that the function which implements the system call gets
other parameters than the system call you've called from userland.
Look at the actual system call implementation in the article and you'll
understand what I mean.
Tom Cosgrove
>
> On Tue, 27 May 2003 invad...@flexcheck.net wrote:
>
> > > On Tue, 27 May 2003 invad...@flexcheck.net wrote:
> > >
> [...]
> >
> > my initial post, but I have a question about C in general. I've seen
> > function definitions like this a lot: int syscall(int, char *)
> >
> > I don't really understand how function prototypes can get away with
> > only giving the data type and not a name for it's arguments. How are
> > these referenced from within the function?
(Not sure why this is on tech@ ... And donning my flame-proof suit for
all the slight inaccuracies that people will no doubt roast me for...)
Err... that's fairly standard C.
Make sure you know the difference between a function declaration, a
function definition, and a function invocation.
Function invocation is calling a function:
rv = strlcpy(dest, src, sizeof(dest)) ;
Functions should be prototyped before being called. This tells the
compiler what types of arguments should be expected in each position,
so that the compiler can tell you if you make a mistake when calling
the function. Functions can be declared either with or without names
for the parameters, but they must have types. Functions are typically
declared in header files (.h), except for static functions, which are
usually declared at the top of the module (.c file) they are used in:
size_t strlcpy(char *dst, const char *src, size_t size) ;
-or-
size_t strlcpy(char *, const char *, size_t) ;
Functions need to be defined so they exist. (!) Parameters must be
given names so that they can be referred to within the function.
There are two ways of doing this, the original method and the ANSI
method. The original K&R way of doing this listed the names of the
paramters and then re-listed the names with the types:
size_t
strlcpy(dst, src, size)
char *dst ;
const char *src ; /* const not avail in trad. C */
size_t size ;
{
/* Implementation goes here */
}
The ANSI method of specifying the function header is much better:
size_t strlcpy(char *dst, const char *src, size_t size)
{
/* Implementation goes here */
}
Note that function declarations have a ; after the closing ) following
the parameters (i.e. no function body).
My personal preference is for the first style of declaration, including
names for the parameters, since this can be created by a quick YP in vi
from the first line of the function definition; just add a ";" at the
end.
And with that all behind us, to directly answer your question:
> > I don't really understand how function prototypes can get away with
> > only giving the data type and not a name for it's arguments. How are
> > these referenced from within the function?
That's the difference between a function prototype/declaration, and the
definition of the function. The function body refers to paramters based
on the first line of its definition. The compiler should complain if
the first line of the definition does not match the declaration (if any).
Hope this helps
Tom
Chris Hedemark
Hash: SHA1
On Tuesday, May 27, 2003, at 12:59 PM, Dries Schellekens wrote:
> There is no need to port PAM to OpenBSD, because OpenBSD uses the BSD
> Authentication framework (originally developed by BSDI).
On Thursday, May 8, 2003, at 09:45 PM, Theo de Raadt wrote:
> It appears obvious why you wrote this new version.
>
> You wanted to re-invent the wheel, making it slightly different, and
> in those slight differences cause people interoperabilty problems. I
> urge everyone out there to avoid using this version. Interoperability
> and simplicity can co-exist, and it is perfectly clear to me at least
> that multiple versions move against these two prime precepts.
>
> I'd love to believe that there are other reasons for writing
> incompatible software, besides the obvious fact that the result shown
> below DOES HAVE INCOMPATIBLITIES. But I can't think of any.
>
> And then some idiot will write code that depends on one of those
> incompatibilities. And then it will break on all other versions. I
> know! We should now add something that is incompatible with yours!
> Oh this all makes the world so much better!
>
> At least this time we know who to blame. Thanks for stepping
> forward. Therefore, I post this for the archives.....
Now of course Theo was talking about something other than PAM. But
it's true, BSD Auth is a reinvention of the wheel that causes people
interoperability problems. The lack of PAM and nsswitch continues to
keep OpenBSD in an infrastructure appliance role or standalone server
on most networks.
- --
War is Terrorism with a Bigger Budget
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.2 (Darwin)
iEYEARECAAYFAj7UwFgACgkQYPuF4Zq9lvYPtgCg8PswWNlNZEYgUOlTL2/vAv8M
/LMAoN+1xa0sr7JZgD9fOrtQgEEc967G
=pKth
-----END PGP SIGNATURE-----
Will Backman
http://mail-index.netbsd.org/tech-userlevel/2001/06/26/0000.html
Noriyuki Soda wrote:
> In summary
> PAM:
> - all PAM modules are to effect setuid when they are
> called from root privilege processes.
> BSD module:
> - all BSD auth modules are to effect setuid when they
> are called from root privilege processes.
> - all setuid BSD auth modules are of course setuid,
> even it it is called from normal user.
My understanding of this is that:
* PAM is not necessarily implemented using shared library/objects
e.g. RedHat is using some external programs for PAM IIRC
* PAM is not really standardized; it's different on every
system which is using it (Solaris, Linux, FreeBSD at least)
If we compare standard implementation of PAM and BSD auth (i.e.
shared objects for PAM, external programs for BSD auth), we get:
* BSD auth module is small, easy to audit external program; rogue BSD auth
module cannot do evil things to caller, since they live in separate address
space and communicate via well-defined API
* BSD auth module does not need to be suid if it's authentication method
doesn't require root access
* it's easy to provide e.g. Linux PAM-compatible authentication API, if need be
* PAM requires the caller to have necessary permissions to authenticate
the user; for most systems, that means the caller has to still be (suid) root
* PAM needs dynamic loading support, so doesn't work for statically linked
programs.
As I see it, BSD auth requires less from the caller, can be used by statically
compiled programs without problems and (suid) caller cannot be attacked
by a bogus PAM module. The only advantage of PAM is that more people
know the TLA PAM, other standardization mostly doesn't exist.
IMHO BSD auth is more suitable from security and usability POW.
Bob Beck wrote:
>>Now of course Theo was talking about something other than PAM. But
>>it's true, BSD Auth is a reinvention of the wheel that causes people
>>interoperability problems. The lack of PAM and nsswitch continues to
>>keep OpenBSD in an infrastructure appliance role or standalone server
>>on most networks.
>>
>>
>
> Wow, my eyes are open for the first time. the lack of PAM and
>nsswitch relegates an os to an infrastructire appliance role or
>standalone server on most networks.. Gee, If only I'd noticed that
>before. Thanks for educating us. I must talk to Bill Gates, it
>explains the position of all the windows machines on my network. I'm
>sure Microsoft will be quick to adopt PAM and nsswitch to break out of
>the infrastructure and standalone server niche.
>
> -Bob
Chuck Yerkes
> >Now of course Theo was talking about something other than PAM. But
> >it's true, BSD Auth is a reinvention of the wheel that causes people
> >interoperability problems. The lack of PAM and nsswitch continues to
> >keep OpenBSD in an infrastructure appliance role or standalone server
> >on most networks.
>
> Wow, my eyes are open for the first time. the lack of PAM and
> nsswitch relegates an os to an infrastructire appliance role or
> standalone server on most networks..
Lack of nsswitch, or really a generic wrapper for the get...(3)
routines (getpwent(), getprotoby...(), etc), means that we have NIS
for name services rather than being able to extend them (LDAP scales
a bit better than NIS).
While BSDAuth addresses the password/auth part of the game, a
machine with no /etc/passwd entries for a user is less than
functional.
I really don't want dynamically loaded (or changable on the fly)
libraries for name services, but being able to say something like:
group: files, ldap (query="gid=%0,dc=NIS,dc=example,dc=com" group)
would be really nice.
PAM varies, yes. I attended the Usenix talk that Ted T'so did
about seeing PAM at Sun and implementing it for Linux a year
before Sun had anything out. I'd suggest that it's an existing
wheel that could be fixed. Done well, perhaps the other BSDs
do what they did with Theo's NIS stuff: adopt it wholesale.
Damien Miller
> Now of course Theo was talking about something other than PAM. But
> it's true, BSD Auth is a reinvention of the wheel that causes people
> interoperability problems.
Why does OpenBSD "need" PAM? OpenBSD already has a system which
accomplishes what PAM offers. I suppose you just want Buzzword
compliance with Linux and some of the other BSDs.
PAM is a terrible API and is completely unsuited to modern applications.
Its main query/response function runs in a blocking mode, its standard
is buggy and ambiguous[1] and (not suprisingly) the implementations of
the standard vary greatly.
The modules themselves are another horror. There is little
standardisation of modules either in their names or the arguments they
accept. Many modules make assumptions about the environment in which
they are which are not covered by the PAM RFC. Many modules are (in my
experience) buggy.
I'd love to see someone port the BSD auth API to other platforms - it is
better in every way.
-d
Chris Hedemark
> Why does OpenBSD "need" PAM? OpenBSD already has a system which
> accomplishes what PAM offers. I suppose you just want Buzzword
> compliance with Linux and some of the other BSDs.
Well, maybe it doesn't need PAM. But it needs (or, more accurately,
people like me need for it) to authenticate users against LDAP. The
Solaris, Linux and OS X boxes are all doing it (Solaris being a big
pain in the ass, BTW) but it's supported.
And no, don't bother posting the LDAP via Radius kluge again. I've
seen it.
> I'd love to see someone port the BSD auth API to other platforms - it
> is
> better in every way.
Or, more importantly, make the BSD auth API a more useful alternative
by implementing popular centralized authentication methods with it.
And, still, without the nsswitch it's only one component of centralized
logins. One of the biggest pieces, nsswitch, is missing all together.
Alejandro G. Belluscio
NNF> I came across ypAnything last time I looked through PAM vs. BSD auth
NNF> discussions. I haven't tried it myself but it looks fairly simple and
NNF> small and provides functionality of nsswitch. Here's the link:
NNF> http://www.radux.com/ypAnything/
>> Why not write a NIS -> LDAP proxy?
>>
>> That would take the complexity out of libc and, by implication,
>> privileged code.
After so much discussion, I would like to know the technical
difficulties to have BSD Auth and LDAP. Pointers anyone?
---
Regards,
Alejandro Belluscio
Dries Schellekens
You could start by looking at login_ldap by Peter Werner
(http://www.ifost.org.au/~peterw/). It's already it the ports tree:
sysutils/login_ldap.
According to the CAVEATS section of its manpage login_ldap(8)
OpenBSD does not ship with an ldap server in the default install, however
OpenLDAP is available via packages(7).
Until OpenBSD gets an nsswitch implementation or something similar, every
user in the LDAP server will need to have a valid passwd file entry. This
can be achieved by using the useradd(8) utility with similar arguments to
this: useradd -m -d /home/peterw -s /bin/sh -L ldap peterw
As of version 3.3 login_ldap no longer installs setuid root. It is
believed that elevated priveledges are not neccessary in most cases, but
potentially this could cause a problem. Making the login_ldap binary
setuid root should be tried as part of site installation debugging if
things aren't working. If you find you do need the setuid bit set,
please let the authors know.
http://www.deadly.org/article.php3?sid=20030311135606 lists some of the
problems of login_ldap
* OpenBSD lacks a nsswitch implementation. Luke Mewburn wrote a nsswitch
implementation for NetBSD and this was ported to FreeBSD 5.
* login_ldap requires OpenLDAP. Someone suggested using tinyldap instead
(http://fefe.de/tinyldap/).
Chuck Yerkes
> On Thu, 29 May 2003, Alejandro G. Belluscio wrote:
>
> > Thursday, May 29, 2003, 2:19:10 PM, you wrote:
> > NNF> I came across ypAnything last time I looked through PAM vs. BSD auth
> > NNF> discussions. I haven't tried it myself but it looks fairly simple and
> > NNF> small and provides functionality of nsswitch. Here's the link:
> > NNF> http://www.radux.com/ypAnything/
> > >> Why not write a NIS -> LDAP proxy?
> > >>
> > >> That would take the complexity out of libc and, by implication,
> > >> privileged code.
> >
> > After so much discussion, I would like to know the technical
> > difficulties to have BSD Auth and LDAP. Pointers anyone?
>
> You could start by looking at login_ldap by Peter Werner
> (http://www.ifost.org.au/~peterw/). It's already it the ports tree:
> sysutils/login_ldap.
And, again, it's for authentication only (which is fine). The missing
bits are an alternative for the YP functionality (but with security
and the ability to run across subnets).