From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 1 Jan 2003 04:46:57 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 0 ************************************************** Tuesday 31 December 2002 Number 0 ************************************************** Subjects for today 1 Re: PASSWD handling : Jeff Robinson 2 Re: PASSWD handling : Jeff Robinson 3 Re: PASSWD handling : John Poltorak 4 Re: PASSWD handling : John Poltorak 5 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 6 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 7 Re: PASSWD handling : Nicholas Sheppard 8 Re: PASSWD handling : Nicholas Sheppard 9 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 10 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 11 Re: PASSWD handling : Ted Sikora 12 Re: PASSWD handling : Ted Sikora **= Email 1 ==========================** Date: Wed, 01 Jan 2003 09:57:49 -0600 From: Jeff Robinson Subject: Re: PASSWD handling John Poltorak wrote: > On Tue, Dec 31, 2002 at 11:09:58PM +1000, Andrew MacIntyre wrote: > >>On Tue, 31 Dec 2002, John Poltorak wrote: >> >> >>>I know ZOPE and Mailman use this file but I guess the passwd handling is >>>done by Python. Does this mean Python would have to be rebuilt? >> >>No. The support that Zope & Mailman are using is written in Python, and >>in fact copes with 3 different password file formats. This support is for >>reading only (which is all Python supplies on Unix platforms anyway). >> >>There is some sense in trying to get everyone agreeing on using PAM, > > > For those people (like me) who had never heard of PAM, check:- > > http://www.kernel.org/pub/linux/libs/pam/ > > (I assume that is the correct PAM...) > > > >>but I suspect that the amount of work is a negative, especially for >>established codebases. > > > > I don't think there are too many OS/2 programs which access PASSWD, so > introducing a new authentication method shouldn't present too big a > problem. > > What may be an interesting exercise is well would be to check what Cygwin( http://www.cygwin.com/ ) has done with their programs to access password files, just to see if they have come up with a solution that can be directly adapted. The Cygwin stuff would presumably run into some of the same problems we have, such as drive letters so might offer an implementation to look at. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 2 ==========================** Date: Wed, 01 Jan 2003 09:57:49 -0600 From: Jeff Robinson Subject: Re: PASSWD handling John Poltorak wrote: > On Tue, Dec 31, 2002 at 11:09:58PM +1000, Andrew MacIntyre wrote: > >>On Tue, 31 Dec 2002, John Poltorak wrote: >> >> >>>I know ZOPE and Mailman use this file but I guess the passwd handling is >>>done by Python. Does this mean Python would have to be rebuilt? >> >>No. The support that Zope & Mailman are using is written in Python, and >>in fact copes with 3 different password file formats. This support is for >>reading only (which is all Python supplies on Unix platforms anyway). >> >>There is some sense in trying to get everyone agreeing on using PAM, > > > For those people (like me) who had never heard of PAM, check:- > > http://www.kernel.org/pub/linux/libs/pam/ > > (I assume that is the correct PAM...) > > > >>but I suspect that the amount of work is a negative, especially for >>established codebases. > > > > I don't think there are too many OS/2 programs which access PASSWD, so > introducing a new authentication method shouldn't present too big a > problem. > > What may be an interesting exercise is well would be to check what Cygwin( http://www.cygwin.com/ ) has done with their programs to access password files, just to see if they have come up with a solution that can be directly adapted. The Cygwin stuff would presumably run into some of the same problems we have, such as drive letters so might offer an implementation to look at. Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 3 ==========================** Date: Wed, 1 Jan 2003 14:28:06 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Dec 31, 2002 at 11:09:58PM +1000, Andrew MacIntyre wrote: > On Tue, 31 Dec 2002, John Poltorak wrote: > > > I know ZOPE and Mailman use this file but I guess the passwd handling is > > done by Python. Does this mean Python would have to be rebuilt? > > No. The support that Zope & Mailman are using is written in Python, and > in fact copes with 3 different password file formats. This support is for > reading only (which is all Python supplies on Unix platforms anyway). > > There is some sense in trying to get everyone agreeing on using PAM, For those people (like me) who had never heard of PAM, check:- http://www.kernel.org/pub/linux/libs/pam/ (I assume that is the correct PAM...) > but I suspect that the amount of work is a negative, especially for > established codebases. I don't think there are too many OS/2 programs which access PASSWD, so introducing a new authentication method shouldn't present too big a problem. > -- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 > andymac at pcug.org.au | Belconnen ACT 2616 > Web: http://www.andymac.org/ | Australia > -- John **= Email 4 ==========================** Date: Wed, 1 Jan 2003 14:28:06 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Dec 31, 2002 at 11:09:58PM +1000, Andrew MacIntyre wrote: > On Tue, 31 Dec 2002, John Poltorak wrote: > > > I know ZOPE and Mailman use this file but I guess the passwd handling is > > done by Python. Does this mean Python would have to be rebuilt? > > No. The support that Zope & Mailman are using is written in Python, and > in fact copes with 3 different password file formats. This support is for > reading only (which is all Python supplies on Unix platforms anyway). > > There is some sense in trying to get everyone agreeing on using PAM, For those people (like me) who had never heard of PAM, check:- http://www.kernel.org/pub/linux/libs/pam/ (I assume that is the correct PAM...) > but I suspect that the amount of work is a negative, especially for > established codebases. I don't think there are too many OS/2 programs which access PASSWD, so introducing a new authentication method shouldn't present too big a problem. > -- > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 > andymac at pcug.org.au | Belconnen ACT 2616 > Web: http://www.andymac.org/ | Australia > -- John **= Email 5 ==========================** Date: Wed, 1 Jan 2003 17:01:02 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 05:41:17PM +0000, John Poltorak wrote: > On Tue, Dec 31, 2002 at 06:15:27PM +0100, Holger Veit wrote: [...] > > The Unix style is IMHO the only way to go; otherwise we run into multiple, > > subtle problems with porting and later software management. The idea > > of UnixOS/2 is to make software tolerant wih drive letters, but also > > have a means to eliminate them entirely, i.e.: If the user passes > > some D:\foo\bar.txt to a program, it should work correctly as if it > > had been a standard Unix style /drive_d/foo/bar.txt path. In the case of > > PASSWD, it is a must to rewrite the drive letter into a Unix style > > convention (e.g. some /drive_d/home/theuser). Whatever convention for > > converting d: -> /some_prefix_for_d is chosen, it must fulfill the following > > constraints: > > - no reserved Unix path character (e.g. a slash for anything else > > than a path component delimiter) > > - Starting with a slash - lots of software still rely on code > > like " if (path[0]=='/') " > > - No Backslashes or Dollar symbols - this will confuse shell scripts. > > >From the passwd entries I've seen the two way of handling c: have been:- > > $c > > c; > > If the first is not acceptable then, then is it easy enough to change apps > which rely on this format? > > Are you suggesting we adopt something like:- ? > > /c; > > > maybe /cĒ ... There is no reason to keep the colon following the drive letter at all (even not substituted with a semicolon or another character). What one would need to implement is a substitution mechanism (a.k.a. "mount"/"umount") which replaces a driveletter+colon with a regular Unix-based path component, and vice versa (where drive letters are required). Thus you get the freedom of having C: mapped to "/yourdrive_c/" on your system, whereas it can be "/drive/letters/c/" on mine. mount/umount accept the associations from some file like (preferrably) /etc/fstab or /etc/vfstab. There are only few locations where drive letters go into the runtime system (open, fopen, stat, and some others). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 6 ==========================** Date: Wed, 1 Jan 2003 17:01:02 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 05:41:17PM +0000, John Poltorak wrote: > On Tue, Dec 31, 2002 at 06:15:27PM +0100, Holger Veit wrote: [...] > > The Unix style is IMHO the only way to go; otherwise we run into multiple, > > subtle problems with porting and later software management. The idea > > of UnixOS/2 is to make software tolerant wih drive letters, but also > > have a means to eliminate them entirely, i.e.: If the user passes > > some D:\foo\bar.txt to a program, it should work correctly as if it > > had been a standard Unix style /drive_d/foo/bar.txt path. In the case of > > PASSWD, it is a must to rewrite the drive letter into a Unix style > > convention (e.g. some /drive_d/home/theuser). Whatever convention for > > converting d: -> /some_prefix_for_d is chosen, it must fulfill the following > > constraints: > > - no reserved Unix path character (e.g. a slash for anything else > > than a path component delimiter) > > - Starting with a slash - lots of software still rely on code > > like " if (path[0]=='/') " > > - No Backslashes or Dollar symbols - this will confuse shell scripts. > > >From the passwd entries I've seen the two way of handling c: have been:- > > $c > > c; > > If the first is not acceptable then, then is it easy enough to change apps > which rely on this format? > > Are you suggesting we adopt something like:- ? > > /c; > > > maybe /cĒ ... There is no reason to keep the colon following the drive letter at all (even not substituted with a semicolon or another character). What one would need to implement is a substitution mechanism (a.k.a. "mount"/"umount") which replaces a driveletter+colon with a regular Unix-based path component, and vice versa (where drive letters are required). Thus you get the freedom of having C: mapped to "/yourdrive_c/" on your system, whereas it can be "/drive/letters/c/" on mine. mount/umount accept the associations from some file like (preferrably) /etc/fstab or /etc/vfstab. There are only few locations where drive letters go into the runtime system (open, fopen, stat, and some others). Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 7 ==========================** Date: Wed, 1 Jan 2003 17:08:52 +1100 (AED) From: Nicholas Sheppard Subject: Re: PASSWD handling On Tue, 31 Dec 2002, John Poltorak wrote: > Assuming you can provide a PASSWD.LIB, how would this be integrated into > any apps which use a PASSWD file? #include and -lpasswd > I know ZOPE and Mailman use this file but I guess the passwd handling is > done by Python. Does this mean Python would have to be rebuilt? If a standard PASSWD.LIB appeared, all the applications that used the passwd file would either have to be re-built with the standard PASSWD.LIB or re-implement PASSWD.LIB internally. Unless they happen to use the standard format already, of course. I don't know anything about particular applications other than Pine. Nicholas S. |\ Location: Wollongong, Australia | Be grateful for every year you live. No |\ E-mail: nps at zeta.org.au | matter how long you live, remember that | WWW: http://www.zeta.org.au/~nps | you will be dead much longer. There is | ---> Cynicism & Negativity | nothing at all to look forward to. - Ecclesiastes 11:18 **= Email 8 ==========================** Date: Wed, 1 Jan 2003 17:08:52 +1100 (AED) From: Nicholas Sheppard Subject: Re: PASSWD handling On Tue, 31 Dec 2002, John Poltorak wrote: > Assuming you can provide a PASSWD.LIB, how would this be integrated into > any apps which use a PASSWD file? #include and -lpasswd > I know ZOPE and Mailman use this file but I guess the passwd handling is > done by Python. Does this mean Python would have to be rebuilt? If a standard PASSWD.LIB appeared, all the applications that used the passwd file would either have to be re-built with the standard PASSWD.LIB or re-implement PASSWD.LIB internally. Unless they happen to use the standard format already, of course. I don't know anything about particular applications other than Pine. Nicholas S. |\ Location: Wollongong, Australia | Be grateful for every year you live. No |\ E-mail: nps at zeta.org.au | matter how long you live, remember that | WWW: http://www.zeta.org.au/~nps | you will be dead much longer. There is | ---> Cynicism & Negativity | nothing at all to look forward to. - Ecclesiastes 11:18 **= Email 9 ==========================** Date: Wed, 1 Jan 2003 17:08:58 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 10:55:31AM -0800, Ken Ames wrote: > hi Adrian, > > Adrian Gschwend wrote: > > > > >NOTE: It does not seem to work with old kernels, I tested it with ACP1 > >kernels first (rev 62 IIRC) but that trapped right at the beginning of > >the boot process, with kernel revision 86 it seems to work just fine. > > > > > ses is kernel version sensitive, each kernel has it's own release of > ses. check the testcase site for kernels and be sure to get the right > packages. This is not really true. There have been some bug fixes after official FP14 for SESDD which Scott has continuously propagated through the various testcase kernels. They are actually the same code. The acompanying DLLs are, as I said earlier, part of the B2 MAC system which is not really what people want to maintain on their hosts. To use SES functions, you basically just need an own driver and the kernel itself. For the kernel, there have been few deviations, e.g. the security export helpers have been extended to also handle the Large File APIs of the SMP kernels. Besides: fixes are cumulative, so if we define a certain kernel level, we can be sure that (unless Scott messes something up in a testcase kernel) a newer kernel will contain the required functionality. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 10 ==========================** Date: Wed, 1 Jan 2003 17:08:58 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 10:55:31AM -0800, Ken Ames wrote: > hi Adrian, > > Adrian Gschwend wrote: > > > > >NOTE: It does not seem to work with old kernels, I tested it with ACP1 > >kernels first (rev 62 IIRC) but that trapped right at the beginning of > >the boot process, with kernel revision 86 it seems to work just fine. > > > > > ses is kernel version sensitive, each kernel has it's own release of > ses. check the testcase site for kernels and be sure to get the right > packages. This is not really true. There have been some bug fixes after official FP14 for SESDD which Scott has continuously propagated through the various testcase kernels. They are actually the same code. The acompanying DLLs are, as I said earlier, part of the B2 MAC system which is not really what people want to maintain on their hosts. To use SES functions, you basically just need an own driver and the kernel itself. For the kernel, there have been few deviations, e.g. the security export helpers have been extended to also handle the Large File APIs of the SMP kernels. Besides: fixes are cumulative, so if we define a certain kernel level, we can be sure that (unless Scott messes something up in a testcase kernel) a newer kernel will contain the required functionality. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 11 ==========================** Date: Wed, 01 Jan 2003 18:57:55 -0500 From: Ted Sikora Subject: Re: PASSWD handling Nicholas Sheppard wrote: > On Wed, 1 Jan 2003, Jeff Robinson wrote: > > >>What may be an interesting exercise is well would be to check what >>Cygwin( http://www.cygwin.com/ ) has done with their programs to access >>password files, just to see if they have come up with a solution that >>can be directly adapted. The Cygwin stuff would presumably run into >>some of the same problems we have, such as drive letters so might offer >>an implementation to look at. > > > The passwd file in my Cygwin installation does not have drive letters in > it; all files in Cygwin are assumed to be beneath some Cygwin root > directory which is invisible to applications. I believe UnixOS/2 has a > similar notion with UNIXROOT or some such thing? Yup! I don't define a drive letter anymore in builds. --with-path=/zope or --with-python=/apps/python/python.exe Everything seems to run smoother too. I build with bash then try to run solely with cmd or make wrappers for #!/bin/sh scripts in the bin. Without the letter defined you can put it on any drive. I see some ports like Perl for instance has the drive o: defined as an env variable because it was built on o:\ > > To access files outside the Cygwin hierarchy, Cygwin has special > directories /cygdrive/c, /cygdrive/d, etc. that map to the usual Windows > drive letters, similar to the solution suggested by Holger. > > For the sake of a passwd file, I would be happy to use the /cygdrive > solution. It eliminates the need for special characters and it seems to > work fine under Cygwin. But I'm not sure about the implicit root > directory stuff because I want my applications to behave as an OS/2 user > would expect them to. > That's a good idea. We should find out how they do it and 'steal it'. GPL right? -- Ted Sikora tsikora at ntplx.net **= Email 12 ==========================** Date: Wed, 01 Jan 2003 18:57:55 -0500 From: Ted Sikora Subject: Re: PASSWD handling Nicholas Sheppard wrote: > On Wed, 1 Jan 2003, Jeff Robinson wrote: > > >>What may be an interesting exercise is well would be to check what >>Cygwin( http://www.cygwin.com/ ) has done with their programs to access >>password files, just to see if they have come up with a solution that >>can be directly adapted. The Cygwin stuff would presumably run into >>some of the same problems we have, such as drive letters so might offer >>an implementation to look at. > > > The passwd file in my Cygwin installation does not have drive letters in > it; all files in Cygwin are assumed to be beneath some Cygwin root > directory which is invisible to applications. I believe UnixOS/2 has a > similar notion with UNIXROOT or some such thing? Yup! I don't define a drive letter anymore in builds. --with-path=/zope or --with-python=/apps/python/python.exe Everything seems to run smoother too. I build with bash then try to run solely with cmd or make wrappers for #!/bin/sh scripts in the bin. Without the letter defined you can put it on any drive. I see some ports like Perl for instance has the drive o: defined as an env variable because it was built on o:\ > > To access files outside the Cygwin hierarchy, Cygwin has special > directories /cygdrive/c, /cygdrive/d, etc. that map to the usual Windows > drive letters, similar to the solution suggested by Holger. > > For the sake of a passwd file, I would be happy to use the /cygdrive > solution. It eliminates the need for special characters and it seems to > work fine under Cygwin. But I'm not sure about the implicit root > directory stuff because I want my applications to behave as an OS/2 user > would expect them to. > That's a good idea. We should find out how they do it and 'steal it'. GPL right? -- Ted Sikora tsikora at ntplx.net