Re: Shadow vss PAM
Date: Wed, 21 Aug 96 11:59 PDT From: [EMAIL PROTECTED] (Bruce Perens) Cc: debian-devel@lists.debian.org (Debian Development) Patrick Weemeeuw writes: I would propose to go for shadow for 1.2. In the mean time, I will try to make a few applications PAM-aware, to wet my feet and to gain some insight about how simple or complex things are. After all, it's not a black or white thing, but we can PAMify application by application. Good decision. If I understand you correctly, we can set PAM to authenticate via shadow password only and deploy it in a piece-wise fashion. Then, once we have it deployed fully, we can start to introduce additional methods of validation. Thanks Bruce Even better yet: as soon as any application has been adapted to PAM it can use all available PAM modules immediately (as configured by the system administrator per application), independently of the status of other authentication clients. I also hope that the support for shadow passwords is compatible with the current shadow package: that would avoid most transition problems. Patrick.
Re: Shadow vss PAM
Date: Tue, 20 Aug 96 08:19 PDT From: [EMAIL PROTECTED] (Bruce Perens) Reply-To: Bruce Perens [EMAIL PROTECTED] From: Patrick Weemeeuw [EMAIL PROTECTED] The big question is: is PAM ready for integration in the distribution? I agree that it sounds like a better way to do the job. I think the interested parties should decide together if they are able to deploy it reasonably _soon_. I have started work on the installation floppies for 1.2, we are about to change the source format and convert a lot of packages, we have architecture changes to merge in, etc., so you probably have a month but not much more. Thanks Bruce Well, I do have some areas of concern, both pro and against introducing PAM now. Introducing PAM is certainly not a free lunch: it needs some changes to rather many components of the distribution [including probably changes to some unexpected ones such as e.g. init for session logging--this is still in discussion on the mailing list]. This is certainly easier to do with a more centralised control as in the RedHat distribution, than in our distributed development model. In this light, a month is on the short side, and it might be easier to wait and see how RedHat solves the hasles. On the other hand, we do not need complete PAM support in 1.2, but might well start with a few PAMified applications. However, I think that a commitment of Debian to PAM in the long term, is important. My second concern is that introducing the shadow support now might make a later introduction of PAM more difficult. Technically, conversion from a unix password authentication scheme to PAM is simpler than from unix + shadow to PAM (this might or might not be a big issue, depending maybe on how compatible the PAM shadow module is with the Debian shadow package). Thinking things over again, and considering that the shadow support for Debian is almost finished (as far as I know, only xdm and a few small utilities such as vipw have to be adapted for shadow support), I would propose to go for shadow for 1.2. In the mean time, I will try to make a few applications PAM-aware, to wet my feet and to gain some insight about how simple or complex things are. After all, it's not a black or white thing, but we can PAMify application by application. Patrick
Bug#4120: rdist ssh
Package: netstd
Version: 2.06-1
Currently the netstd package contains rdist version 6.1.
Could this please be upgraded to version 6.1.1 or 6.1.2,
so that it works with ssh?
Thanks.
--
From the ssh FAQ:
4.4 Can I use rdist with ssh?
Stock rdist 6.1.0 does not work together with ssh, due to bugs in it. The
6.1.1 versions of rdist and
later versions are believed to work.
If you use rdist, don't forget to compile the path to ssh into it.
Alternatively, you may specify the -P
option so rdist uses ssh, and not rsh.
If you use password authentication with rdist 6.1.2, you will need to apply
the following patch to
rdist to make it work:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
/* child. we use sp[1] to be stdin/stdout, and close
sp[0]. */
(void) close(sp[0]);
- if (dup2(sp[1], 0) 0 || dup2(0,1) 0 || dup2(0, 2) 0) {
+ if (dup2(sp[1], 0) 0 || dup2(0,1) 0) {
error(dup2 failed: %s., SYSERR);
_exit(255);
}
Bug#4070: snmpd: hrStorageSize fix
Package: snmp Version: 2.1.2l4-1 The following patch fixes the problem of integer wrap around that occurs for =2Gb disks (i.e. sbuf.f_blocks * sbuf.f_bsize 2^31). This is accomplished by computing the intermediate values in floating point. Patrick. -- --- snmp-2.1.2l4/agent/snmp_vars.c Sun Aug 20 23:02:21 1995 +++ snmp-2.1.2l4.patched/agent/snmp_vars.c Wed Aug 7 13:17:24 1996 @@ -3514,11 +3525,11 @@ break; case HRSTORAGESIZE: long_return = idx 2 ? hr_getstor (idx, HRSTORAGESIZE, 1024) : - (sbuf.f_blocks * sbuf.f_bsize) / 1024; + (long)(((float)sbuf.f_blocks * (float)sbuf.f_bsize) / 1024.0 + 0.5 ); break; case HRSTORAGEUSED: long_return = idx 2 ? hr_getstor (idx, HRSTORAGEUSED, 1024) : - ((sbuf.f_blocks-sbuf.f_bfree) * sbuf.f_bsize) / 1024; + (long)(((float)(sbuf.f_blocks-sbuf.f_bfree) * sbuf.f_bsize) / 1024 .0 + 0.5); break; case HRSTORAGEALLOCFAILURES: long_return = 0;/* XXX: dummy */
PAM libraries (libpam) uploaded
I have uploaded the initial release of libpam to chiark. There is also a copy available on ftp://ftp.kulnet.kuleuven.ac.be/pub/people/patrick/debian. The libpam package contains the PAM libraries (PAM = Pluggable Authentication Modules [http://gluon.physics.ucla.edu/~morgan/pam http://www.redhat.com/pam]). The current libraries have an experimental nature: the main logic is OK, but only a limited set of underlying authentication modules is available for the moment (other modules are under development). However, the libraries are stable enough to start making application programs (authentication clients) PAM aware. I am releasing this package now, because I think that it's now the time to consider making applications PAM aware: development is currently accellerating, and RedHat is PAM-ifying some authentication clients for their next release. As a consequence we can use the same or similar diffs for most of our applications. If you would PAM-ify your application, please join the Linux-PAM mailing list ([EMAIL PROTECTED]). -BEGIN PGP SIGNED MESSAGE- Date: 04 Aug 96 06:53 UT Format: 1.6 Distribution: unstable Urgency: Low Maintainer: Patrick Weemeeuw [EMAIL PROTECTED] Source: libpam Version: 0.50-1 Binary: libpam Architecture: i386 source Description: libpam: Pluggable Authentication Modules -- Libraries Changes: initial release Files: 977e5542dd94866ba6030457035f6017 265966 - libpam_0.50-1.tar.gz 1cebc86544ded0b5d67cdd2abbb10a40 107224 - libpam_0.50-1.diff.gz 8cee7a269c830e413b207b1a43ef4978 224980 misc extra libpam_0.50-1_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.2i iQEVAwUBMgRJxugIvbi48kGNAQH1Vgf9GFUBTVE42+gCltXTCyzsa3k1zJtWAHJA //fCKKr9Jk1wFNNXhZkE14ayNU4dbLSJK9LXnOJsGKMT53qfVUrDsgl9GeIvgfLx lcMBblxCWqmYaPWgKCzmcBF3X8/n/wuezPTMQJvxS/7ILoqZiuES1Hm5HNRS48pj ejEzXj6yJGmsWZQ901kY40tz6lUEL9K1wvYZERXFf/Zbt9tWN6MV5w/K9nKF8O4b NyVfgbrdoNG3tA4yHCfUoZebCbc9N+EoSNPjjv9E0qIIleJUAThi8bbm1k3u9RoJ IDpZv01FglO4mA/uOC99MVSxhTAvFIZVgb9zJJ7DPZPx3z1QLkg2FQ== =3/QK -END PGP SIGNATURE-
Towards support for S/Key
A common source of security problems is often that each service uses its own protocol and code for authentication (ftpd, telnetd, rlogind, login, popd, ...). Besides the inconsistent user interface, this also introduces many oportunities for security holes. This holds in particular for public domain software, for which there is no centralised code management. As we are integrating all these packages into one high quality distribution, I think that this point is worth our attention. Separating authentication code into one library, would offer the following benefits: - consistent interface for all utilities - more security (at least if the library itself is also properly protected) - it becomes much more easy to plug in alternative authentication methods, e.g. S/Key. BTW: a similar thing has been done with the readline library (I'm not sure about this, but at least I have noticed that ftp has command line editing). On the other hand, I don't think that this modularity is easily achieved, as it interferes with many packages. Perhaps more debian-knowledgeable people can add their comments? -- Patrick Weemeeuw, network manager K.U.Leuven, KULeuvenNet, currently at the Dept. of Computer Science Celestijnenlaan 200 A, B-3001 Leuven, Belgium Tel: +32 16 327635 Fax: +32 16 327996 E-mail: [EMAIL PROTECTED] PGP key: ftp://ftp.kulnet.kuleuven.ac.be/pub/people/patrick/pgpkey.asc
