[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Reserving new module name



I wrote:
>I really wanted to use the logindevperm format for compatibility, but
>it just doesn't have enough information in it.  I need at least two
>new columns, and I want symbolic permissions, and I want regexps for
>filenames (very important) and console device definitions (also
>important).
>
>(I'm also doing more, but that's unrelated to the config file format.)
>
>So go ahead and do pam_logindevperm and we won't conflict.

Well, I managed to make the extended file format backwards-compatible
with /etc/logindevperm EXCEPT that I use regexps instead of globs for
the filenames.  Once it's ready (I've got it working, but it's in
hack mode -- uses lex, yacc, and glib right now, and doesn't accept
any arguments), all you would need to do is add a logindevperm argument
that changed from regexps to globs when parsing filenames and changed
the filename from /etc/security/console.perms to /etc/logindevperm.

It also is a bit extended; I allow things like this:
user A logs on at console 1  (A gets all permissions as well as authentication)
user B logs on at console 2  (B doesn't have permissions, but will authenticate)
user A logs off of console 1 (B's condition doesn't change
user B logs on at console 1  (B now has full permissions)
user B logs off of console 1 (B -- still on console 2 -- still has full perms)
user B logs off of console 2 (all permissions now reverted to default)

There's a single file (/var/lock/console.lock by default; that can be
an option later) that controls console permissions grabbing.  Authentication
and reference counting are done with /var/lock/console/<username> files
(again, the directory name could be configurable) which contain an
effectively unbounded number (int) represented in ascii which is the
reference count for that user.  The /var/lock/console/<username> file is
used to authenticate console access to applications which use pam_console
as an auth module.  That is, if /var/lock/console/<username> exists,
the auth component succeeds.  That can of course be stacked with password
authentication or any other kind of authentication you want.

As an aside, although I am using lex and yacc, I managed not to export
any symbols that I'm not supposed to, in part by using a sed script to
munge all the lex and yacc output, in part by resolving interdependencies
between the files, and finally by doing the pam_pwdb trick of
#include "otherfile.c"
several times.  Yes, using lex and yacc is a bug, as is linking against
glib, but it made for much faster coding the first time around.  If anyone
comes up with a really good reason to use lex and/or yacc in a pam
module, I've got the infrastructure to do it cleanly from the pam point
of view, and so I can give you a hand.

I don't think pam_console is ready for release yet, but I wanted to give
an update on my progress.

Oh, and I added
#define CAST_ME_HARDER (const void**)
and then
    pam_get_item(pamh, PAM_SERVICE, CAST_ME_HARDER &service);
At least it makes me feel better.  I still think we should dump the
stupid cast.  It's really bad to tell the compiler to ignore all its
typechecking info that it has available, as we do in EVERY SINGLE CALL
to pam_get_item in EVERY SINGLE MODULE in Linux-PAM.  CAST_ME_HARDER
is an ugly hack, but it at least expresses the fact that it's a hack
more so than sticking the explicit casts in there as if they belong.

michaelkjohnson

"Magazines all too frequently lead to books and should be regarded by the
 prudent as the heavy petting of literature."            -- Fran Lebowitz
 Linux Application Development       http://www.redhat.com/~johnsonm/lad/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []