Nalin Dahyabhai | 1 Oct 17:13 2002
Picon

Re: flag field in shadow field

On Fri, Sep 27, 2002 at 10:26:00AM -0400, Phanidhar Koganti wrote:
> There is this sp_flags field in the /etc/shadow file which is reserved
> for future use.
> Does anyone have any idea if it is safe to use it for a custom field
> needed for my application.

It's not safe.  The field is reserved for future use, either by the
shadow maintainers or the libc maintainers, and can't reliably be used
for anything else (consider the case where two applications decided that
it was okay to use the field for their own purposes -- things would get
ugly very quickly).

Cheers,

Nalin
Pat Suwalski | 6 Oct 02:04 2002

Upgrade Woes with Apache.

Hello,

I'm one of the people who run a system with about 2000 users.

We've been using Authen:PAM with Perl for a web script where users can 
set some of their preferences.

Today I upgraded pam-0.72-37.i386.rpm to pam-0.75-18.7 and the script 
has since stopped working.

I've spent all day making some test scripts. Turns out that whereas the 
apache user could previously test the validity of users based on 
username/password, now only root and the user being tested can do this.

Does anyone know if this was a recent change, or maybe we were running a 
modified version?

More importantly, does anyone know of a (hopefully simple) solution to 
this dilemma?

Thanks.

--

-- 
Pat Suwalski, EngSoc Administrator
Faculty of Engineering, Carleton University
[pat <at> engsoc.org]
Pat Suwalski | 6 Oct 02:27 2002

Re: Upgrade Woes with Apache.

Actually, chmod u+s seems to have solved the problem. I still don't know 
if this is the 'correct' solution, but it sure works.

--Pat

Pat Suwalski wrote:
> Hello,
> 
> I'm one of the people who run a system with about 2000 users.
> 
> We've been using Authen:PAM with Perl for a web script where users can 
> set some of their preferences.
> 
> Today I upgraded pam-0.72-37.i386.rpm to pam-0.75-18.7 and the script 
> has since stopped working.
> 
> I've spent all day making some test scripts. Turns out that whereas the 
> apache user could previously test the validity of users based on 
> username/password, now only root and the user being tested can do this.
> 
> Does anyone know if this was a recent change, or maybe we were running a 
> modified version?
> 
> More importantly, does anyone know of a (hopefully simple) solution to 
> this dilemma?
> 
> Thanks.
> 

--

-- 
(Continue reading)

W. Michael Petullo | 6 Oct 15:34 2002

Re: pam_mount on Debian (woody)

On Fri, Sep 27, 2002 at 01:47:32PM +0200, Florian Lohoff wrote:
> On Fri, Sep 27, 2002 at 01:17:50PM +0200, Holger Levsen wrote:
> > Hello world ;)
> > 
> > I try to get pam_mount-0.3.8 working on Debian GNU/Linux 3.0, but I
> > don't succeed - although I succeeded half a year ago with
> > pam_mount-0.3.1 or so...

The new pam_mount 0.3.9 release should fix the main Debian issue.
The tarball is available at http://www.flyn.org.

--

-- 
Mike

:wq
Holger Levsen | 7 Oct 18:09 2002
Picon

pam-0.3.9 working with debian ?

hi,

thankfully today Mike uploaded a new version of pam-mount, 0.3.9, which
should fix the debian-issues. But I didn't fix it on my systems here, so
I am asking you, whether you had any success with it and Debian (woody)?

I'll post my configs (again) if needed.

regards,   Holger

--
http://www.hbt.de - Hamburger Berater Team GmbH
Zachariah Mully | 8 Oct 18:40 2002

Redhat 7.1 pam_userdb bug

Hello all-
	I'm trying to install vsftpd on one of my RH7.1 boxes and I'd like to
use it's virtual user feature, but I am having issues with pam_userdb.
	There was a bug filed about the following with PAM-0.74:
Oct  4 14:17:59 fuzzylumpkins vsftpd: PAM unable to
dlopen(/lib/security/pam_userdb.so)
Oct  4 14:17:59 fuzzylumpkins vsftpd: PAM [dlerror:
/lib/security/pam_userdb.so: undefined symbol: conversation]
Oct  4 14:17:59 fuzzylumpkins vsftpd: PAM adding faulty module:
/lib/security/pam_userdb.so

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pam/Linux-PAM/modules/pam_userdb/Makefile.diff?r1=1.3&r2=1.4
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43979

	Because this is a production server, I can't take it down and I am
afraid of fubar'ing it with a complete re-install of PAM, so instead I
downloaded the SRPMS for the package PAM-0.74-22 and patched the
pam_userdb Makefile as described in the above cvs diff. 

[root <at> fuzzylumpkins pam-0.74]# pwd 
/usr/src/redhat/SOURCES/pam-0.74
[root <at> fuzzylumpkins pam-0.74]# make
.....
[root <at> fuzzylumpkins pam-0.74]# cd modules/pam_userdb/
[root <at> fuzzylumpkins pam_userdb]# make install
mkdir -p /lib/security
/usr/bin/install -c -m 755 pam_userdb.so /lib/security
[root <at> fuzzylumpkins pam_userdb]# 

Even after doing this (and recompiling vsftpd) I still get the same
(Continue reading)

stw | 12 Oct 02:11 2002
Picon

Unknown PAM message

I´m in trouble trying to figure out the meaning of the following 
message in /var/log/messages on my Red Hat 7.2 (kernel 2.4.7-
10custom) server:

Oct  8 06:37:46 server su(pam_unix)[17201]: session opened for 
user root by (uid=0)
Oct  8 06:37:51 server su(pam_unix)[17201]: session closed for user 
root

First I thought It was something related to a root login on the console, 
but the message in that case wouldn´t be like this one. Notice the 
missing username data after the "by". I´m lost. HELP PLEASE

Thanks

Sergio Tschá
Tha
Mathias Krüger | 12 Oct 02:33 2002
Picon

Re: Unknown PAM message

guess that was change user

you logged in with su.

eto wsjo!

quoting stw <at> hotlink.com.br, 11.10.2002 17:11:30:
> I´m in trouble trying to figure out the meaning of the following 
> message in /var/log/messages on my Red Hat 7.2 (kernel 2.4.7-
> 10custom) server:
> 
> Oct  8 06:37:46 server su(pam_unix)[17201]: session opened for 
> user root by (uid=0)
> Oct  8 06:37:51 server su(pam_unix)[17201]: session closed for user 
> root
> 
> First I thought It was something related to a root login on the console, 
> but the message in that case wouldn´t be like this one. Notice the 
> missing username data after the "by". I´m lost. HELP PLEASE
> 
> Thanks
> 
> Sergio Tschá
> Tha
> 
> 
> 
> _______________________________________________
> Pam-list mailing list
> Pam-list <at> redhat.com
(Continue reading)

Sergio Tschá Wanderley | 12 Oct 02:33 2002
Picon

Re: Unknown PAM message

OK, it sure was, but who did It?

When I change user using "su" the message looks like this:

Oct  8 06:37:46 server su(pam_unix)[17201]: session opened for
user root by mylogin (uid=2423)
Oct  8 06:37:51 server su(pam_unix)[17201]: session closed for user
root

So, its not the same thing...

Thanks anyway.
----- Original Message -----
From: "Mathias Krüger" <m.krueger <at> digidrops.de>
To: <pam-list <at> redhat.com>
Sent: Friday, October 11, 2002 9:33 PM
Subject: Re: Unknown PAM message

> guess that was change user
>
> you logged in with su.
>
> eto wsjo!
>
> quoting stw <at> hotlink.com.br, 11.10.2002 17:11:30:
> > I´m in trouble trying to figure out the meaning of the following
> > message in /var/log/messages on my Red Hat 7.2 (kernel 2.4.7-
> > 10custom) server:
> >
> > Oct  8 06:37:46 server su(pam_unix)[17201]: session opened for
(Continue reading)

KhoGuan PhuaN | 13 Oct 07:59 2002
Picon

pam_wheel: su to non-root vs. su to root


The security policy enforced by pam_wheel.so module is to grant
privilege of su'ing to `both root and non-root' only to people
in a privileged group(default wheel group, if not found, group with 
gid=0). I think it's overkilling. The reasoning is as follows:

1. It should do just what it claims to do: "only permit root
    authentication to members of wheel group", but no more. That is,
    leave non-root authentication alone.

2. Even if it's desirable to restrict su'ing to non-root, and to
    incorporate this function into pam_wheel, it should be implemented
    in a different level, perhaps by designing different arguments for
    pam_wheel. Su'ing to root has much more security concern than su'ing
    to general users. And the latter would be very convenient for two
    users who trust each other and share each other's passwords. The
    admin should not deprive their humble wishes of doing that. It's not
    related to the wheel group membership. The policy is UNFAIR that they
    are not allowed to su to each other just because they are not members
    of the wheel group, which has only to do with system maintenance they
    would never be interested in.

Yet another concern comes to me: what about su'ing to wheel members by
non-wheel members. Should it be implemented in yet another different
pam_wheel argument. Maybe it's good, maybe it's overkilling on the other 
end.

Should I file a `bug' report? Or do I over-sympathize with the dummy
users who are always messing things up. Any suggestion and correction 
would be highly appreciated.
(Continue reading)


Gmane