|
Home > Archive > Debian Developers > March 2004 > Seeking comments on PAM logging change
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Seeking comments on PAM logging change
|
|
| Sam Hartman 2004-03-13, 2:34 pm |
|
[Copies to me; I'm on debian-devel but very behind and don't really
have enough time to read it]
Bug #213566 is another complaint about how PAM handles logging.
Currently PAM_unix calls openlog in the pam library in an attempt to
make sure that PAM authentication messages are logged claiming to be
from the PAM service name (pam_unix) instead of from the application
or in cases of applications that do not call openlog, from unnamed
syslog lines.
The submitter of this bug argued convincingly that calling openlog is
an inappropriate abstraction violation. Libraries should not modify
global state such as the syslog configuration. Modules that are
plugins to libraries especially should not do this.
Sun has apparently also removed calls to openlog from their PAM
implementation.
It is my intent to remove this call to openlog. Doing so may very
well change the format of messages logged by PAM application. This is
both a heads up and a chance for you to convince me I'm wrong.
--Sam
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Oliver Kurth 2004-03-13, 3:33 pm |
| On Sat, 2004-03-13 at 10:09, Sam Hartman wrote:
> [Copies to me; I'm on debian-devel but very behind and don't really
> have enough time to read it]
>
>
> Bug #213566 is another complaint about how PAM handles logging.
> Currently PAM_unix calls openlog in the pam library in an attempt to
> make sure that PAM authentication messages are logged claiming to be
> from the PAM service name (pam_unix) instead of from the application
> or in cases of applications that do not call openlog, from unnamed
> syslog lines.
>
> The submitter of this bug argued convincingly that calling openlog is
> an inappropriate abstraction violation. Libraries should not modify
> global state such as the syslog configuration. Modules that are
> plugins to libraries especially should not do this.
I agree here. In the report it is said that PAM handles this way:
- PAM can allow modules (and the library itself) to log information
using the syslog facility, and require applications to re-establish
any application syslog settings after every call to libpam
This is not acceptable, and places an inappropriate limit to application
that use PAM. It is okay for _modules_ to restrict the use of syslog,
but _not_ for an application.
IMHO the real cause is a syslog design problem: instead of having one
global 'instance', openlog() should return a handle, which has to be
given to each syslog() call. But there is not much that can be done
about that, unless someone volunteers to implement an alternative
syslog() library.
A much better way would be to require an application to provide a
callback for logging - this way the application may decide to not use
syslog at all but something different. Option #2 in the report log. This
would also allow the library to give a name tag in the syslog line, to
show where the message originated.
> Sun has apparently also removed calls to openlog from their PAM
> implementation.
>
> It is my intent to remove this call to openlog. Doing so may very
> well change the format of messages logged by PAM application. This is
> both a heads up and a chance for you to convince me I'm wrong.
Although I agree with you on the problem, I think this should be really
handled by upstream, otherwise you make it incompatible.
Greetings,
Oliver
| |
| Sam Hartman 2004-03-13, 6:34 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[color=darkred]
Oliver> Although I agree with you on the problem, I think this
Oliver> should be really handled by upstream, otherwise you make
Oliver> it incompatible.
As far as I'm concerned, Debian PAM is basically forked from the
upstream already. Upstream does not act on patches in a reasonable
time line; upstream does not respond to mail questions; upstream
releases versions of PAM that cannot work with applications like cron
or ssh
I do try to make sure that I have a number of patches open against
upstream PAM on the off chance they ever get reviewed. I will try and
resync with PAM releases from time to time; I chose not to care about
0.77 but will hopefully care about the next PAM release.
If you think this sucks, you're right. If you think you can do a
better job of getting upstream to listen than I, be my guest.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFAU3bt/ I12czyGJg8RAoiHAJ4xRzChGVTAH8J3Kegk6DcPO
RQ+qACfe22f
wRv+rOol7dndPhzMiQoyBYg=
=xjgr
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-03-14, 2:33 am |
| On Sun, 14 Mar 2004 08:02, Sam Hartman <hartmans@debian.org> wrote:
>
> Oliver> Although I agree with you on the problem, I think this
> Oliver> should be really handled by upstream, otherwise you make
> Oliver> it incompatible.
>
> As far as I'm concerned, Debian PAM is basically forked from the
> upstream already. Upstream does not act on patches in a reasonable
> time line; upstream does not respond to mail questions; upstream
> releases versions of PAM that cannot work with applications like cron
> or ssh
Would you be interested in taking over PAM development? If so then I will be
interested in working with you when I get a quiet time in my work (probably
about June I can spend some serious coding time on PAM).
I think that if you lead a PAM fork based on 0.77 + Debian patches + Red Hat
patches then Red Hat will adopt it. I've talked about taking over PAM myself
and no-one seems to have a great opposition to the idea, it's just that I
lack time.
> If you think this sucks, you're right. If you think you can do a
> better job of getting upstream to listen than I, be my guest.
I think that forking PAM is the right thing to do.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russell Coker 2004-03-14, 2:33 am |
| On Sun, 14 Mar 2004 05:09, Sam Hartman <hartmans@debian.org> wrote:
> Bug #213566 is another complaint about how PAM handles logging.
> Currently PAM_unix calls openlog in the pam library in an attempt to
> make sure that PAM authentication messages are logged claiming to be
> from the PAM service name (pam_unix) instead of from the application
> or in cases of applications that do not call openlog, from unnamed
> syslog lines.
Why not do system("logger ...")?
Running the logger program will allow you to set the tag and facility without
interfering with anything else, and it will also support being called from an
application that has never called openlog() (there is no requirement that an
application call openlog() before using PAM AFAIK).
This seems like a neat solution which is easy to code and does not have
side-affects.
NB It's expected that PAM modules can call external programs such as
unix_chkpwd.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|