From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 31 Dec 2002 04:44:36 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 412 ************************************************** Monday 30 December 2002 Number 412 ************************************************** Subjects for today 1 Re: Security/2 (was: Re: useradd, userdel, usermod) : Ted Sikora 2 Re: Security/2 (was: Re: useradd, userdel, usermod) : Ted Sikora 3 fcntl.h : Ted Sikora 4 Re: PASSWD handling : John Poltorak 5 useradd, userdel, usermod : John Poltorak 6 Re: Security/2 (was: Re: useradd, userdel, usermod) : Ken Ames 7 Security/2 (was: Re: useradd, userdel, usermod) : Adrian Gschwend" 8 Re: Security/2 (was: Re: useradd, userdel, usermod) : John Poltorak 9 Re: Security/2 (was: Re: useradd, userdel, usermod) : John Poltorak 10 Re: Security/2 (was: Re: useradd, userdel, usermod) : Adrian Gschwend" 11 Re: fcntl.h : John Poltorak 12 Applying patches to read only files : John Poltorak 13 Re: PASSWD handling : Nicholas Sheppard 14 bootpd : John Poltorak 15 Re: Security/2 (was: Re: useradd, userdel, usermod) : John Poltorak 16 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 17 Re: Security/2 (was: Re: useradd, userdel, usermod) : Holger Veit 18 Re: PASSWD handling : Andrew MacIntyre **= Email 1 ==========================** Date: Tue, 31 Dec 2002 08:24:19 -0500 From: Ted Sikora Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) Adrian Gschwend wrote: > > On Tue, 31 Dec 2002 09:54:32 +0000, John Poltorak wrote: > > >Where can I find the source for useradd, userdel and usermod, along with > >equivalent commands for handling the GROUP file and any other commands for > >managing the PASSWD file? > > > >Does anyone know where such commands are hidden away in the Slackware > >distribution? > > I highly recommend you to have a look at Security/2, nickk (the current > porter of SSH for OS/2) wrote this package based on SES API calls. It > provides user management and ACL's on OS/2, his latest port of sshd is > using it for user management. I installed it on my system and it seems > to work, however I didn't had the time to test it yet. He also provides > a user.exe to add users and acls.exe for ACL lists. > > SES is really the only way to do that properly, it would be nice if > more people could have a look at it and give feedback to nickk. > > 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. > We need to stick to one format for the passwd/group files too. The Python/Zope passwd file appears corrupted to Postgesql. Using os2usr or postgres renders the passwd file useless for Zope and so on. I have had to define different /etc directories for all these. I don't understand why the standard unix format was not used in the first place on these ports. -- Ted **= Email 2 ==========================** Date: Tue, 31 Dec 2002 08:43:24 -0500 From: Ted Sikora Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) Ted Sikora wrote: > > Adrian Gschwend wrote: > > > > On Tue, 31 Dec 2002 09:54:32 +0000, John Poltorak wrote: > > > > >Where can I find the source for useradd, userdel and usermod, along with > > >equivalent commands for handling the GROUP file and any other commands for > > >managing the PASSWD file? > > > > > >Does anyone know where such commands are hidden away in the Slackware > > >distribution? > > They are in the Shadow-4.0.3 package in /a1 Might be a good idea to port this. -- Ted **= Email 3 ==========================** Date: Tue, 31 Dec 2002 08:56:50 -0500 From: Ted Sikora Subject: fcntl.h Anyone have a modified fcntl.h for emx? I'm having problems with locking and those uid bits again! Or better yet a FAQ somewhere on workarounds for os2emx. -- Ted **= Email 4 ==========================** Date: Tue, 31 Dec 2002 09:39:47 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Dec 31, 2002 at 04:57:05PM +1100, Nicholas Sheppard wrote: > On Sun, 29 Dec 2002, John Poltorak wrote: > > > incorporate more Unix programs which require its presence. Unfortunately > > their appear to be at least two standards on OS/2 for the format of this > > file, which differ as to how embedded drive letters should be handled. > > > > It seems that the use of os2user.exe (or user.exe) can render entries > > unusable for other apps which require the file, but in a different format. > > > > What is the best way of resolving this problem? At least in the short > > term... > > There was long discussion on this subject about a year ago, out of which I > chose to use Andy Zabalotny's (sshd) solution as it was the only > implementation I was aware of and I didn't want to re-invent the wheel. > > So far as I know, the format of the file isn't ultimately important, the > important thing is that everyone agrees on it, which requires either > spontaneous agreement from all the developers out there or an executive > decision from "the person in charge". Well since there isn't anyone 'in charge' as such, it's a matter of getting ceratain people to agree with your suggestion. > > Having a common PASSWD handler would be useful, but we can't incorporate > > that into EMX. We don't want every single app having to process the file > > individually, but I can't see what alternatives are available. > > During the previous discussion I suggested I'd like to have a PASSWD.LIB > or similar to implement a common API that we can all use. I don't know > what Andy thinks but I would be happy to make such a thing using Andy's > code (or any other code anyone cares to give me) for the next release of > Pine, and release it as an independent unit as a move towards a (de facto) > standard passwd solution. Andy isn't currently on the list, and I don't know if anyone has any contact with him. If they have, maybe they could find out his views... Assuming you can provide a PASSWD.LIB, how would this be integrated into any apps which use a PASSWD file? 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? What about Perl? Would rebuilding Perl automatically provide the correct handlng for passwd? What other apps use passwd? I'm not sure about MySQL, but I know PostGres uses it... I suspect ProFTPD does too, and there is a chance of that getting ported soon, so it would be good not to have to cater for OS/2's lack of such a file. > Nicholas S. > > |\ Location: Wollongong, Australia | If pigs could vote, the man with the > |\ E-mail: nps at zeta.org.au | slop bucket would be elected swineherd > | WWW: http://www.zeta.org.au/~nps | every time, no matter how much > | ---> Cynicism & Negativity | slaughtering he did on the side. > > - Orson Scott Card -- John **= Email 5 ==========================** Date: Tue, 31 Dec 2002 09:54:32 +0000 From: John Poltorak Subject: useradd, userdel, usermod Where can I find the source for useradd, userdel and usermod, along with equivalent commands for handling the GROUP file and any other commands for managing the PASSWD file? Does anyone know where such commands are hidden away in the Slackware distribution? -- John **= Email 6 ==========================** Date: Tue, 31 Dec 2002 10:55:31 -0800 From: Ken Ames Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) 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. >URL: >http://en.ecomstation.ru/openssh/ > >Details about the concept: >http://en.ecomstation.ru/openssh/readme.eng > >cu > >Adrian > > > Ken > > **= Email 7 ==========================** Date: Tue, 31 Dec 2002 11:47:54 +0100 (CET) From: "Adrian Gschwend" Subject: Security/2 (was: Re: useradd, userdel, usermod) On Tue, 31 Dec 2002 09:54:32 +0000, John Poltorak wrote: >Where can I find the source for useradd, userdel and usermod, along with >equivalent commands for handling the GROUP file and any other commands for >managing the PASSWD file? > >Does anyone know where such commands are hidden away in the Slackware >distribution? I highly recommend you to have a look at Security/2, nickk (the current porter of SSH for OS/2) wrote this package based on SES API calls. It provides user management and ACL's on OS/2, his latest port of sshd is using it for user management. I installed it on my system and it seems to work, however I didn't had the time to test it yet. He also provides a user.exe to add users and acls.exe for ACL lists. SES is really the only way to do that properly, it would be nice if more people could have a look at it and give feedback to nickk. 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. URL: http://en.ecomstation.ru/openssh/ Details about the concept: http://en.ecomstation.ru/openssh/readme.eng cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 8 ==========================** Date: Tue, 31 Dec 2002 12:00:58 +0000 From: John Poltorak Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 11:47:54AM +0100, Adrian Gschwend wrote: > On Tue, 31 Dec 2002 09:54:32 +0000, John Poltorak wrote: > > >Where can I find the source for useradd, userdel and usermod, along with > >equivalent commands for handling the GROUP file and any other commands for > >managing the PASSWD file? > > > >Does anyone know where such commands are hidden away in the Slackware > >distribution? > > I highly recommend you to have a look at Security/2, nickk (the current > porter of SSH for OS/2) wrote this package based on SES API calls. It > provides user management and ACL's on OS/2, his latest port of sshd is > using it for user management. I installed it on my system and it seems > to work, however I didn't had the time to test it yet. He also provides > a user.exe to add users and acls.exe for ACL lists. > > SES is really the only way to do that properly, it would be nice if > more people could have a look at it and give feedback to nickk. I don't really know much about SES. Does it provide a way for OS/2 to appear as a multi-user system? Can we somehow map SES to PASSWD and GROUP or at least make it functionally equivalent? If we do have a PASSWD.LIB maybe that could handle any access to a PASSWD/GROUP file without actually requiring one... > 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. If it requires a specific kernel to work, it isn't something we can use as a generic solution for handling users/password at the moment, but it's something we should bear in mind for the future. I'm not aware of any restriction on a UnixOS/2 distro at the moment in terms of a minimum level of OS/2. I don't even know if Warp 4 is required let alone MCP1/2. > URL: > http://en.ecomstation.ru/openssh/ > > Details about the concept: > http://en.ecomstation.ru/openssh/readme.eng > > cu > > Adrian > > > -- > Adrian Gschwend > at netlabs.org > > ktk [a t] netlabs.org > ------- > Free Software for OS/2 and eCS > http://www.netlabs.org > -- John **= Email 9 ==========================** Date: Tue, 31 Dec 2002 13:31:45 +0000 From: John Poltorak Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 08:24:19AM -0500, Ted Sikora wrote: > We need to stick to one format for the passwd/group files too. The > Python/Zope passwd file appears corrupted to Postgesql. Using os2usr or > postgres renders the passwd file useless for Zope and so on. I have had > to define different /etc directories for all these. I don't understand > why the standard unix format was not used in the first place on these > ports. The standard Unix format uses ':' to seperate fields in PASSWD, but this character is used by OS/2 to specify drive letters, hence the problem is due to different ways of incorporating X: into PASSWD. > -- > Ted -- John **= Email 10 ==========================** Date: Tue, 31 Dec 2002 13:34:48 +0100 (CET) From: "Adrian Gschwend" Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, 31 Dec 2002 12:00:58 +0000, John Poltorak wrote: >I don't really know much about SES. Does it provide a way for OS/2 to >appear as a multi-user system? Can we somehow map SES to PASSWD and GROUP I think SES is the only way to go, however for details I simply don't know enough about it. Probably Holger could give some light into that or nickk. >or at least make it functionally equivalent? If we do have a PASSWD.LIB >maybe that could handle any access to a PASSWD/GROUP file without actually >requiring one... I think nickk is working on make it functionally equivalent. As I said he is using that for sshd and future versions of sshd won't work without it. >If it requires a specific kernel to work, it isn't something we can use as >a generic solution for handling users/password at the moment, but it's >something we should bear in mind for the future. well what's wrong about updating the kernel? Most people can do that I guess, quite easy. >I'm not aware of any restriction on a UnixOS/2 distro at the moment in >terms of a minimum level of OS/2. I don't even know if Warp 4 is required >let alone MCP1/2. ok but power users don't really bother which kernel they use I would say cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 11 ==========================** Date: Tue, 31 Dec 2002 14:37:05 +0000 From: John Poltorak Subject: Re: fcntl.h On Tue, Dec 31, 2002 at 08:56:50AM -0500, Ted Sikora wrote: > Anyone have a modified fcntl.h for emx? There's one include with Posix/2:- http://hobbes.nmsu.edu/pub/os2/dev/misc/p2alpha3.zip > I'm having problems with locking > and those uid bits again! Or better yet a FAQ somewhere on workarounds > for os2emx. Check Alexander Mai's porting guide:- http://homepages.tu-darmstadt.de/~st002279/os2/porting.html > > -- > Ted -- John **= Email 12 ==========================** Date: Tue, 31 Dec 2002 15:26:51 +0000 From: John Poltorak Subject: Applying patches to read only files Is there any way to force PATCH to apply a patch to a read only file? -- John **= Email 13 ==========================** Date: Tue, 31 Dec 2002 16:57:05 +1100 (AED) From: Nicholas Sheppard Subject: Re: PASSWD handling On Sun, 29 Dec 2002, John Poltorak wrote: > incorporate more Unix programs which require its presence. Unfortunately > their appear to be at least two standards on OS/2 for the format of this > file, which differ as to how embedded drive letters should be handled. > > It seems that the use of os2user.exe (or user.exe) can render entries > unusable for other apps which require the file, but in a different format. > > What is the best way of resolving this problem? At least in the short > term... There was long discussion on this subject about a year ago, out of which I chose to use Andy Zabalotny's (sshd) solution as it was the only implementation I was aware of and I didn't want to re-invent the wheel. So far as I know, the format of the file isn't ultimately important, the important thing is that everyone agrees on it, which requires either spontaneous agreement from all the developers out there or an executive decision from "the person in charge". > Having a common PASSWD handler would be useful, but we can't incorporate > that into EMX. We don't want every single app having to process the file > individually, but I can't see what alternatives are available. During the previous discussion I suggested I'd like to have a PASSWD.LIB or similar to implement a common API that we can all use. I don't know what Andy thinks but I would be happy to make such a thing using Andy's code (or any other code anyone cares to give me) for the next release of Pine, and release it as an independent unit as a move towards a (de facto) standard passwd solution. Nicholas S. |\ Location: Wollongong, Australia | If pigs could vote, the man with the |\ E-mail: nps at zeta.org.au | slop bucket would be elected swineherd | WWW: http://www.zeta.org.au/~nps | every time, no matter how much | ---> Cynicism & Negativity | slaughtering he did on the side. - Orson Scott Card **= Email 14 ==========================** Date: Tue, 31 Dec 2002 17:32:16 +0000 From: John Poltorak Subject: bootpd What is the latest version of bootpd and where does it come from? -- John **= Email 15 ==========================** Date: Tue, 31 Dec 2002 17:41:17 +0000 From: John Poltorak Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 06:15:27PM +0100, Holger Veit wrote: > On Tue, Dec 31, 2002 at 01:31:45PM +0000, John Poltorak wrote: > > On Tue, Dec 31, 2002 at 08:24:19AM -0500, Ted Sikora wrote: > > > > > We need to stick to one format for the passwd/group files too. The > > > Python/Zope passwd file appears corrupted to Postgesql. Using os2usr or > > > postgres renders the passwd file useless for Zope and so on. I have had > > > to define different /etc directories for all these. I don't understand > > > why the standard unix format was not used in the first place on these > > > ports. > > > > > > The standard Unix format uses ':' to seperate fields in PASSWD, but this > > character is used by OS/2 to specify drive letters, hence the problem is > > due to different ways of incorporating X: into PASSWD. > > 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Ē ... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) -- John **= Email 16 ==========================** Date: Tue, 31 Dec 2002 18:15:27 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 01:31:45PM +0000, John Poltorak wrote: > On Tue, Dec 31, 2002 at 08:24:19AM -0500, Ted Sikora wrote: > > > We need to stick to one format for the passwd/group files too. The > > Python/Zope passwd file appears corrupted to Postgesql. Using os2usr or > > postgres renders the passwd file useless for Zope and so on. I have had > > to define different /etc directories for all these. I don't understand > > why the standard unix format was not used in the first place on these > > ports. > > > The standard Unix format uses ':' to seperate fields in PASSWD, but this > character is used by OS/2 to specify drive letters, hence the problem is > due to different ways of incorporating X: into PASSWD. 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. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 17 ==========================** Date: Tue, 31 Dec 2002 18:32:21 +0100 From: Holger Veit Subject: Re: Security/2 (was: Re: useradd, userdel, usermod) On Tue, Dec 31, 2002 at 01:34:48PM +0100, Adrian Gschwend wrote: > On Tue, 31 Dec 2002 12:00:58 +0000, John Poltorak wrote: > > >I don't really know much about SES. Does it provide a way for OS/2 to > >appear as a multi-user system? Can we somehow map SES to PASSWD and GROUP > > I think SES is the only way to go, however for details I simply don't > know enough about it. Probably Holger could give some light into that > or nickk. > > >or at least make it functionally equivalent? If we do have a PASSWD.LIB > >maybe that could handle any access to a PASSWD/GROUP file without actually > >requiring one... > > I think nickk is working on make it functionally equivalent. As I said > he is using that for sshd and future versions of sshd won't work > without it. I've yet to look at what nickk wrote, but I agree with Adrian that there is no way without a certain degree of SES. SES has the facilities to implement B1 level mandatory access control (not just the C2 level that Unix can normally reach - B1 is more strict), which means in a positive sense that it can be very secure, in a negative sense, it might serve as a core for TCPA as well. You can also enforce different personalities on the host, a.k.a. multiuser support. There are two ways to do it: - the SES way, as described in the RedBook; this will result in a rather bureaucratic way of security management which is probably not what we really want, - the API way in which the kernel's system entrypoints are intercepted and modified towards a secure system. After long experimenting, I tend to the second strategy even if the first one promises faster and easier to achieve results. The drawback of the first "ought-to-be" strategy is that you get a lot of new daemon processes with specific functions that are flexible but difficult to handle; due to some rather long paths between application and security system (through the SES DLLs), performance will be severely degraded. This is tolerable for systems that really want mandatory access control (military systems) but not for average systems. > >If it requires a specific kernel to work, it isn't something we can use as > >a generic solution for handling users/password at the moment, but it's > >something we should bear in mind for the future. > > well what's wrong about updating the kernel? Most people can do that I > guess, quite easy. I found SES to work fine with any (+/- Scott's experimental testcase stuff) post-FP13 kernel, even for API intercepts. > >I'm not aware of any restriction on a UnixOS/2 distro at the moment in > >terms of a minimum level of OS/2. I don't even know if Warp 4 is required > >let alone MCP1/2. > > ok but power users don't really bother which kernel they use I would > say Enforce an FP14 or later kernel which means we are on a safe side. Ignore the people who want to insist you to hack for outdated stuff and unneccessarily jump through obscure backward compatibility hoops. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 18 ==========================** Date: Tue, 31 Dec 2002 23:09:58 +1000 (est) From: Andrew MacIntyre Subject: Re: PASSWD handling 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, but I suspect that the amount of work is a negative, especially for established codebases. > What other apps use passwd? I'm not sure about MySQL, but I know > PostGres uses it... I suspect ProFTPD does too, and there is a chance of > that getting ported soon, so it would be good not to have to cater for > OS/2's lack of such a file. Most code actually only wants to read passwd files, as many systems don't actually maintain usable passwords in them any more (they're too insecure - even most Linux systems use at least shadow passwords). Anything that wants to run on recent OSes and wants to deal with passwords/authentication has to be prepared to go beyond the passwd file (though most pkgs still include the old code for backward compatibility), and use environments like NIS, NIS+, LDAP, or Kerberos. PAM is a relatively standardised interface to these authentication environments, as well as shadow passwords and classic passwd files. It is probably possible to have a PAM module that authenticates against a LAN Server (especially if there's PAM support for authenticating to an NT environment or Samba). -- 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