You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Benno L. <ben...@id...> - 2004-05-03 07:15:25
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_de.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Andrew M. <ae...@bi...> - 2002-05-10 12:17:31
|
Richard, Everything is working fine now, thank you very much for your help. I plan to upload 4 files to the sorceforge area when I work out how to do it correctly, these are: authprocess.h authprocess.c readconfig.c passwdsecure.c Regards AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: "Harris, Richard" <ha...@ta...> To: "'Andrew McGlashan'" <ae...@bi...> Cc: <pas...@li...>; "Mario Piazzese" <Mar...@se...>; "Bill Lucas" <bil...@se...> Sent: Friday, May 10, 2002 5:08 PM Subject: RE: SEWL passwdsecure -- other note > Hi Andrew, > > Is it working now? > > The sprintf will put the '\0' on the end of hexStringDigit for you but I > guess it doesn't hurt to do it explicitly. > > Richard > > -----Original Message----- > From: Andrew McGlashan [mailto:ae...@bi...] > Sent: Friday, 10 May 2002 5:08 PM > To: Harris, Richard > Cc: pas...@li...; Mario Piazzese; Bill Lucas > Subject: Re: SEWL passwdsecure -- other note > > > Updated .c files attached > > Richard, > > Thanks for your input. I have added an extra line to your supplied MD5File > function. After the 16 unsigned chars have been placed as 32 string chars > (0-31), I added the string terminator char to array position 32 as follows: > hexStringDigest[32] = '\0'; > > Regards > > AndrewM > > Andrew McGlashan AACS > Director > > Mobile: 04 2574 1827 > > Affinity Vision Australia Pty Ltd > ABN 91 099 273 855 > > This message contains privileged and confidential information intended only > for the use of the addressee named above. If you are not the intended > recipient of this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. If you have > received this message in error please notify Affinity Vision Australia Pty > Ltd at ae...@bi... Any views expressed in this message are those of the > individual sender, except where the sender specifically states them to be > the views of Affinity Vision Australia Pty Ltd > > ----- Original Message ----- > From: "Harris, Richard" <ha...@ta...> > To: "'Andrew McGlashan'" <ae...@bi...>; "Harris, Richard" > <ha...@ta...> > Cc: "Bill Lucas" <bil...@se...>; "Mario Piazzese" > <Mar...@se...>; <pas...@li...> > Sent: Friday, May 10, 2002 3:18 PM > Subject: RE: SEWL passwdsecure -- other note > > > > Hi Andrew, > > > > Looking at the truss output the problem seem symtematic of a buffer > overrun > > or a stray pointer being accessed. I've had a look at authprocess.c and > > found a couple of strong contenders. > > > > You've changed the way MD5File works so it returns the MD5 data as a hex > > string, rather than the raw MD5 data. I assume you've done this for the > > purposes of debugging so you can see the checksum more easily. You've > made > > a few mistakes in doing this. > > > > Firstly, in MD5File (if the digest is calculated correctly) you return > > buffer2, unfortunately buffer2 is on the stack so as soon as you return > from > > MD5File the memory where you are pointing to will no longer exist. Later > on > > you then call free on the returned value, this will cause all sorts of > > confusion! Also digest is being created on the heap but you don't return > a > > pointer to it so it creates a memory leak. > > > > To do it your way MD5File should be: > > > > #ifdef USE_MD5 > > char* MD5File(char* filename) > > { > > FILE* file; > > if ((file = fopen (filename, "rb")) == NULL) > > { > > > > #ifdef DEBUG > > fprintf(stderr, "Problem opening file: %s ...\n", filename); > > #endif > > > > return (char*)NULL; > > } > > else { > > MD5_CTX context; > > int len; > > unsigned char buffer[1024]; > > unsigned char digest[16]; > > unsigned int i; > > char* hexStringDigest; > > > > MD5Init (&context); > > while (len = fread (buffer, 1, 1024, file)) > > MD5Update (&context, buffer, len); > > MD5Final (digest, &context); > > > > fclose (file); > > > > /* 33 chars, 32 for hexString, and 1 for NULL */ > > hexStringDigest = (char*)malloc(sizeof(char)*33); > > checkMalloc((void*)hexStringDigest); > > > > for (i = 0; i < 16; i++) > > { > > sprintf(hexStringDigest + i*2, "%02x", digest[i] ); > > } > > > > return hexStringDigest; > > } > > } > > #endif > > > > I havn't got a machine to compile this on to test but it looks all right. > > > > The other big problem is with md5thusfar. At line 144 you define > md5thusfar > > as a char* and then (at line 220) you call strncpy to it before it is > > initialised. It might be pointing at anything at this stage. > > > > You need to change line 220 from: > > strncpy(md5thusfar, file[0], 32); > > to: > > md5thusfar = (char*)malloc(sizeof(char)*33); > > checkMalloc((void*)md5thusfar); > > strncpy(md5thusfar, file[0], 32); > > md5thusfar[32] = '\0'; > > > > Note the last line, if file[0] is 32 or more characters long then > md5thusfar > > won't finish with a null, so trouble will ensue. > > > > That's all of the problems I can see in authprocess.c at the moment. If > you > > fix those problems you should be in with a much better shot of getting it > to > > work. > > > > Regards, > > Richard > > > > PS: As a formatting point when you have something like: > > <tab>func(first_arg, > > <tab> second_arg); > > You shouldn't change it to > > <tab>func(first_arg, > > <tab><tab>second_arg); > > As the arguments won't line up if someone is using different sized tab > > stops. You should always tab to specify indents and space to line up a > > command the spreads multiple lines. The same applies for if/while > > conditions and for statements. > > > > PPS: I've made you an admin of the sourceforge project. > > > > > > -----Original Message----- > > From: Andrew McGlashan [mailto:ae...@bi...] > > Sent: Thursday, 9 May 2002 10:45 AM > > To: Harris, Richard > > Cc: Bill Lucas; Mario Piazzese > > Subject: Fw: SEWL passwdsecure -- other note > > Importance: High > > > > > > Richard, > > > > I have made this email high priority as SE Water has a number of uses that > > will need to use the passwdsecure tool. Bill has even suggested that I be > > listed as a maintainer to try to progress this quicker; I would really > like > > some more help. > > > > Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK > > works. I have since re-worked that but I still have some problems. The > > FILEICMP looks okay after all, although I haven't actually tested it; I > > didn't look at it closely enough to understand it before. > > > > The problem I am having now with the re-worked FILECMP / MD5CHECK section > > having been done has to do with the getPsinfo function; it is dropping out > > without completing all checks. I don't know why it dumps out, but here is > > the statement that is failing: > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > fileinfo); > > > > Other information (from the non-Linux code): > > > Checking file types / sizes... > > > > > > int sizeRead /* always 336 if successful */ > > > int sizeReadTotal /* always 0 */ > > > > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > > > Now it fails after a number of iterations. I did remove a single check > from > > one require group and it got through to an additional require group. I > was > > going to include the output file with the debug information, but I don't > > have it with me right now. Let me know if you need it and I will > endeavour > > to get it to you. > > > > I did adjust the following in the getPsinfo function: > > from FILE* fileinfo; > > to FILE *fileinfo; > > I assume that was simply a typo. The change didn't help or seem to effect > > anything. I also made sure that every fopen had an fclose; I thought that > > maybe there were too many files open or something like that. Maybe there > is > > still something in this as it was quite late when I packed it in last > night. > > > > The Makefile in the attached source has a DEBUG entry added to the CFLAGS > > line, so it always makes the debug version for now. My 'do_conf' doesn't > > include the MD5 directory, however, it uses the found OpenSSL libraries > and > > thus the configure defines USE_MD5. > > > > AndrewM > > > > Andrew McGlashan AACS > > Director > > > > Mobile: 04 2574 1827 > > > > Affinity Vision Australia Pty Ltd > > ABN 91 099 273 855 > > > > This message contains privileged and confidential information intended > only > > for the use of the addressee named above. If you are not the intended > > recipient of this message you are hereby notified that you must not > > disseminate, copy or take any action in reliance on it. If you have > > received this message in error please notify Affinity Vision Australia Pty > > Ltd at ae...@bi... Any views expressed in this message are those of > the > > individual sender, except where the sender specifically states them to be > > the views of Affinity Vision Australia Pty Ltd > > > > ----- Original Message ----- > > From: <And...@se...> > > To: <ae...@bi...> > > Sent: Thursday, May 09, 2002 1:12 AM > > Subject: SEWL passwdsecure -- other note > > > > > > > > > > The following statement fails consistently for unknown reasons....., > > > but only after so many reads... > > > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > > fileinfo); > > > > > > > > > Checking file types / sizes... > > > > > > int sizeRead /* always 336 if successful */ > > > int sizeReadTotal /* always 0 */ > > > > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > > > > > > **************************************************************************** > ******* > > The information in this e-mail message and any files transmitted with it > > are intended to be confidential and for the use of only the individual or > > entity to whom they are addressed. The message and files may be > > protected by legal professional privilege, or other legal rules. The > > confidentiality of and privilege applying to this message and > > files is not waived if this message or files has been sent to you by > mistake. > > If the reader of this message or files is not the intended recipient, you > are > > notified that retention, distribution or copying of this message and files > are > > strictly prohibited. If you receive this message or files in error, > please > > notify us immediately by telephone or return e-mail and delete all copies > > from your computer system. It is the recipient's responsibility to check > this > > message and files for viruses. > > > > Thank you. > > > **************************************************************************** > ******* > > > > > ******************************************************* > PLEASE NOTE: This internet email message > has been checked for viruses and appropriate > content to ensure it complies with TABCORP's > electronic communication policy. > ******************************************************* > > > > **************************************************************************** ******* > The information in this e-mail message and any files transmitted with it > are intended to be confidential and for the use of only the individual or > entity to whom they are addressed. The message and files may be > protected by legal professional privilege, or other legal rules. The > confidentiality of and privilege applying to this message and > files is not waived if this message or files has been sent to you by mistake. > If the reader of this message or files is not the intended recipient, you are > notified that retention, distribution or copying of this message and files are > strictly prohibited. If you receive this message or files in error, please > notify us immediately by telephone or return e-mail and delete all copies > from your computer system. It is the recipient's responsibility to check this > message and files for viruses. > > Thank you. > **************************************************************************** ******* > |
From: Harris, R. <ha...@ta...> - 2002-05-10 07:15:58
|
Hi Andrew, Is it working now? The sprintf will put the '\0' on the end of hexStringDigit for you but I guess it doesn't hurt to do it explicitly. Richard -----Original Message----- From: Andrew McGlashan [mailto:ae...@bi...] Sent: Friday, 10 May 2002 5:08 PM To: Harris, Richard Cc: pas...@li...; Mario Piazzese; Bill Lucas Subject: Re: SEWL passwdsecure -- other note Updated .c files attached Richard, Thanks for your input. I have added an extra line to your supplied MD5File function. After the 16 unsigned chars have been placed as 32 string chars (0-31), I added the string terminator char to array position 32 as follows: hexStringDigest[32] = '\0'; Regards AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: "Harris, Richard" <ha...@ta...> To: "'Andrew McGlashan'" <ae...@bi...>; "Harris, Richard" <ha...@ta...> Cc: "Bill Lucas" <bil...@se...>; "Mario Piazzese" <Mar...@se...>; <pas...@li...> Sent: Friday, May 10, 2002 3:18 PM Subject: RE: SEWL passwdsecure -- other note > Hi Andrew, > > Looking at the truss output the problem seem symtematic of a buffer overrun > or a stray pointer being accessed. I've had a look at authprocess.c and > found a couple of strong contenders. > > You've changed the way MD5File works so it returns the MD5 data as a hex > string, rather than the raw MD5 data. I assume you've done this for the > purposes of debugging so you can see the checksum more easily. You've made > a few mistakes in doing this. > > Firstly, in MD5File (if the digest is calculated correctly) you return > buffer2, unfortunately buffer2 is on the stack so as soon as you return from > MD5File the memory where you are pointing to will no longer exist. Later on > you then call free on the returned value, this will cause all sorts of > confusion! Also digest is being created on the heap but you don't return a > pointer to it so it creates a memory leak. > > To do it your way MD5File should be: > > #ifdef USE_MD5 > char* MD5File(char* filename) > { > FILE* file; > if ((file = fopen (filename, "rb")) == NULL) > { > > #ifdef DEBUG > fprintf(stderr, "Problem opening file: %s ...\n", filename); > #endif > > return (char*)NULL; > } > else { > MD5_CTX context; > int len; > unsigned char buffer[1024]; > unsigned char digest[16]; > unsigned int i; > char* hexStringDigest; > > MD5Init (&context); > while (len = fread (buffer, 1, 1024, file)) > MD5Update (&context, buffer, len); > MD5Final (digest, &context); > > fclose (file); > > /* 33 chars, 32 for hexString, and 1 for NULL */ > hexStringDigest = (char*)malloc(sizeof(char)*33); > checkMalloc((void*)hexStringDigest); > > for (i = 0; i < 16; i++) > { > sprintf(hexStringDigest + i*2, "%02x", digest[i] ); > } > > return hexStringDigest; > } > } > #endif > > I havn't got a machine to compile this on to test but it looks all right. > > The other big problem is with md5thusfar. At line 144 you define md5thusfar > as a char* and then (at line 220) you call strncpy to it before it is > initialised. It might be pointing at anything at this stage. > > You need to change line 220 from: > strncpy(md5thusfar, file[0], 32); > to: > md5thusfar = (char*)malloc(sizeof(char)*33); > checkMalloc((void*)md5thusfar); > strncpy(md5thusfar, file[0], 32); > md5thusfar[32] = '\0'; > > Note the last line, if file[0] is 32 or more characters long then md5thusfar > won't finish with a null, so trouble will ensue. > > That's all of the problems I can see in authprocess.c at the moment. If you > fix those problems you should be in with a much better shot of getting it to > work. > > Regards, > Richard > > PS: As a formatting point when you have something like: > <tab>func(first_arg, > <tab> second_arg); > You shouldn't change it to > <tab>func(first_arg, > <tab><tab>second_arg); > As the arguments won't line up if someone is using different sized tab > stops. You should always tab to specify indents and space to line up a > command the spreads multiple lines. The same applies for if/while > conditions and for statements. > > PPS: I've made you an admin of the sourceforge project. > > > -----Original Message----- > From: Andrew McGlashan [mailto:ae...@bi...] > Sent: Thursday, 9 May 2002 10:45 AM > To: Harris, Richard > Cc: Bill Lucas; Mario Piazzese > Subject: Fw: SEWL passwdsecure -- other note > Importance: High > > > Richard, > > I have made this email high priority as SE Water has a number of uses that > will need to use the passwdsecure tool. Bill has even suggested that I be > listed as a maintainer to try to progress this quicker; I would really like > some more help. > > Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK > works. I have since re-worked that but I still have some problems. The > FILEICMP looks okay after all, although I haven't actually tested it; I > didn't look at it closely enough to understand it before. > > The problem I am having now with the re-worked FILECMP / MD5CHECK section > having been done has to do with the getPsinfo function; it is dropping out > without completing all checks. I don't know why it dumps out, but here is > the statement that is failing: > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > Other information (from the non-Linux code): > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > Now it fails after a number of iterations. I did remove a single check from > one require group and it got through to an additional require group. I was > going to include the output file with the debug information, but I don't > have it with me right now. Let me know if you need it and I will endeavour > to get it to you. > > I did adjust the following in the getPsinfo function: > from FILE* fileinfo; > to FILE *fileinfo; > I assume that was simply a typo. The change didn't help or seem to effect > anything. I also made sure that every fopen had an fclose; I thought that > maybe there were too many files open or something like that. Maybe there is > still something in this as it was quite late when I packed it in last night. > > The Makefile in the attached source has a DEBUG entry added to the CFLAGS > line, so it always makes the debug version for now. My 'do_conf' doesn't > include the MD5 directory, however, it uses the found OpenSSL libraries and > thus the configure defines USE_MD5. > > AndrewM > > Andrew McGlashan AACS > Director > > Mobile: 04 2574 1827 > > Affinity Vision Australia Pty Ltd > ABN 91 099 273 855 > > This message contains privileged and confidential information intended only > for the use of the addressee named above. If you are not the intended > recipient of this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. If you have > received this message in error please notify Affinity Vision Australia Pty > Ltd at ae...@bi... Any views expressed in this message are those of the > individual sender, except where the sender specifically states them to be > the views of Affinity Vision Australia Pty Ltd > > ----- Original Message ----- > From: <And...@se...> > To: <ae...@bi...> > Sent: Thursday, May 09, 2002 1:12 AM > Subject: SEWL passwdsecure -- other note > > > > > > The following statement fails consistently for unknown reasons....., > > but only after so many reads... > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > fileinfo); > > > > > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > **************************************************************************** ******* > The information in this e-mail message and any files transmitted with it > are intended to be confidential and for the use of only the individual or > entity to whom they are addressed. The message and files may be > protected by legal professional privilege, or other legal rules. The > confidentiality of and privilege applying to this message and > files is not waived if this message or files has been sent to you by mistake. > If the reader of this message or files is not the intended recipient, you are > notified that retention, distribution or copying of this message and files are > strictly prohibited. If you receive this message or files in error, please > notify us immediately by telephone or return e-mail and delete all copies > from your computer system. It is the recipient's responsibility to check this > message and files for viruses. > > Thank you. > **************************************************************************** ******* > ******************************************************* PLEASE NOTE: This internet email message has been checked for viruses and appropriate content to ensure it complies with TABCORP's electronic communication policy. ******************************************************* *********************************************************************************** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. *********************************************************************************** |
From: Andrew M. <ae...@bi...> - 2002-05-10 07:11:26
|
Updated .c files attached Richard, Thanks for your input. I have added an extra line to your supplied MD5File function. After the 16 unsigned chars have been placed as 32 string chars (0-31), I added the string terminator char to array position 32 as follows: hexStringDigest[32] = '\0'; Regards AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: "Harris, Richard" <ha...@ta...> To: "'Andrew McGlashan'" <ae...@bi...>; "Harris, Richard" <ha...@ta...> Cc: "Bill Lucas" <bil...@se...>; "Mario Piazzese" <Mar...@se...>; <pas...@li...> Sent: Friday, May 10, 2002 3:18 PM Subject: RE: SEWL passwdsecure -- other note > Hi Andrew, > > Looking at the truss output the problem seem symtematic of a buffer overrun > or a stray pointer being accessed. I've had a look at authprocess.c and > found a couple of strong contenders. > > You've changed the way MD5File works so it returns the MD5 data as a hex > string, rather than the raw MD5 data. I assume you've done this for the > purposes of debugging so you can see the checksum more easily. You've made > a few mistakes in doing this. > > Firstly, in MD5File (if the digest is calculated correctly) you return > buffer2, unfortunately buffer2 is on the stack so as soon as you return from > MD5File the memory where you are pointing to will no longer exist. Later on > you then call free on the returned value, this will cause all sorts of > confusion! Also digest is being created on the heap but you don't return a > pointer to it so it creates a memory leak. > > To do it your way MD5File should be: > > #ifdef USE_MD5 > char* MD5File(char* filename) > { > FILE* file; > if ((file = fopen (filename, "rb")) == NULL) > { > > #ifdef DEBUG > fprintf(stderr, "Problem opening file: %s ...\n", filename); > #endif > > return (char*)NULL; > } > else { > MD5_CTX context; > int len; > unsigned char buffer[1024]; > unsigned char digest[16]; > unsigned int i; > char* hexStringDigest; > > MD5Init (&context); > while (len = fread (buffer, 1, 1024, file)) > MD5Update (&context, buffer, len); > MD5Final (digest, &context); > > fclose (file); > > /* 33 chars, 32 for hexString, and 1 for NULL */ > hexStringDigest = (char*)malloc(sizeof(char)*33); > checkMalloc((void*)hexStringDigest); > > for (i = 0; i < 16; i++) > { > sprintf(hexStringDigest + i*2, "%02x", digest[i] ); > } > > return hexStringDigest; > } > } > #endif > > I havn't got a machine to compile this on to test but it looks all right. > > The other big problem is with md5thusfar. At line 144 you define md5thusfar > as a char* and then (at line 220) you call strncpy to it before it is > initialised. It might be pointing at anything at this stage. > > You need to change line 220 from: > strncpy(md5thusfar, file[0], 32); > to: > md5thusfar = (char*)malloc(sizeof(char)*33); > checkMalloc((void*)md5thusfar); > strncpy(md5thusfar, file[0], 32); > md5thusfar[32] = '\0'; > > Note the last line, if file[0] is 32 or more characters long then md5thusfar > won't finish with a null, so trouble will ensue. > > That's all of the problems I can see in authprocess.c at the moment. If you > fix those problems you should be in with a much better shot of getting it to > work. > > Regards, > Richard > > PS: As a formatting point when you have something like: > <tab>func(first_arg, > <tab> second_arg); > You shouldn't change it to > <tab>func(first_arg, > <tab><tab>second_arg); > As the arguments won't line up if someone is using different sized tab > stops. You should always tab to specify indents and space to line up a > command the spreads multiple lines. The same applies for if/while > conditions and for statements. > > PPS: I've made you an admin of the sourceforge project. > > > -----Original Message----- > From: Andrew McGlashan [mailto:ae...@bi...] > Sent: Thursday, 9 May 2002 10:45 AM > To: Harris, Richard > Cc: Bill Lucas; Mario Piazzese > Subject: Fw: SEWL passwdsecure -- other note > Importance: High > > > Richard, > > I have made this email high priority as SE Water has a number of uses that > will need to use the passwdsecure tool. Bill has even suggested that I be > listed as a maintainer to try to progress this quicker; I would really like > some more help. > > Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK > works. I have since re-worked that but I still have some problems. The > FILEICMP looks okay after all, although I haven't actually tested it; I > didn't look at it closely enough to understand it before. > > The problem I am having now with the re-worked FILECMP / MD5CHECK section > having been done has to do with the getPsinfo function; it is dropping out > without completing all checks. I don't know why it dumps out, but here is > the statement that is failing: > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > Other information (from the non-Linux code): > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > Now it fails after a number of iterations. I did remove a single check from > one require group and it got through to an additional require group. I was > going to include the output file with the debug information, but I don't > have it with me right now. Let me know if you need it and I will endeavour > to get it to you. > > I did adjust the following in the getPsinfo function: > from FILE* fileinfo; > to FILE *fileinfo; > I assume that was simply a typo. The change didn't help or seem to effect > anything. I also made sure that every fopen had an fclose; I thought that > maybe there were too many files open or something like that. Maybe there is > still something in this as it was quite late when I packed it in last night. > > The Makefile in the attached source has a DEBUG entry added to the CFLAGS > line, so it always makes the debug version for now. My 'do_conf' doesn't > include the MD5 directory, however, it uses the found OpenSSL libraries and > thus the configure defines USE_MD5. > > AndrewM > > Andrew McGlashan AACS > Director > > Mobile: 04 2574 1827 > > Affinity Vision Australia Pty Ltd > ABN 91 099 273 855 > > This message contains privileged and confidential information intended only > for the use of the addressee named above. If you are not the intended > recipient of this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. If you have > received this message in error please notify Affinity Vision Australia Pty > Ltd at ae...@bi... Any views expressed in this message are those of the > individual sender, except where the sender specifically states them to be > the views of Affinity Vision Australia Pty Ltd > > ----- Original Message ----- > From: <And...@se...> > To: <ae...@bi...> > Sent: Thursday, May 09, 2002 1:12 AM > Subject: SEWL passwdsecure -- other note > > > > > > The following statement fails consistently for unknown reasons....., > > but only after so many reads... > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > fileinfo); > > > > > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > **************************************************************************** ******* > The information in this e-mail message and any files transmitted with it > are intended to be confidential and for the use of only the individual or > entity to whom they are addressed. The message and files may be > protected by legal professional privilege, or other legal rules. The > confidentiality of and privilege applying to this message and > files is not waived if this message or files has been sent to you by mistake. > If the reader of this message or files is not the intended recipient, you are > notified that retention, distribution or copying of this message and files are > strictly prohibited. If you receive this message or files in error, please > notify us immediately by telephone or return e-mail and delete all copies > from your computer system. It is the recipient's responsibility to check this > message and files for viruses. > > Thank you. > **************************************************************************** ******* > |
From: Harris, R. <ha...@ta...> - 2002-05-10 05:26:22
|
Hi Andrew, Looking at the truss output the problem seem symtematic of a buffer overrun or a stray pointer being accessed. I've had a look at authprocess.c and found a couple of strong contenders. You've changed the way MD5File works so it returns the MD5 data as a hex string, rather than the raw MD5 data. I assume you've done this for the purposes of debugging so you can see the checksum more easily. You've made a few mistakes in doing this. Firstly, in MD5File (if the digest is calculated correctly) you return buffer2, unfortunately buffer2 is on the stack so as soon as you return from MD5File the memory where you are pointing to will no longer exist. Later on you then call free on the returned value, this will cause all sorts of confusion! Also digest is being created on the heap but you don't return a pointer to it so it creates a memory leak. To do it your way MD5File should be: #ifdef USE_MD5 char* MD5File(char* filename) { FILE* file; if ((file = fopen (filename, "rb")) == NULL) { #ifdef DEBUG fprintf(stderr, "Problem opening file: %s ...\n", filename); #endif return (char*)NULL; } else { MD5_CTX context; int len; unsigned char buffer[1024]; unsigned char digest[16]; unsigned int i; char* hexStringDigest; MD5Init (&context); while (len = fread (buffer, 1, 1024, file)) MD5Update (&context, buffer, len); MD5Final (digest, &context); fclose (file); /* 33 chars, 32 for hexString, and 1 for NULL */ hexStringDigest = (char*)malloc(sizeof(char)*33); checkMalloc((void*)hexStringDigest); for (i = 0; i < 16; i++) { sprintf(hexStringDigest + i*2, "%02x", digest[i] ); } return hexStringDigest; } } #endif I havn't got a machine to compile this on to test but it looks all right. The other big problem is with md5thusfar. At line 144 you define md5thusfar as a char* and then (at line 220) you call strncpy to it before it is initialised. It might be pointing at anything at this stage. You need to change line 220 from: strncpy(md5thusfar, file[0], 32); to: md5thusfar = (char*)malloc(sizeof(char)*33); checkMalloc((void*)md5thusfar); strncpy(md5thusfar, file[0], 32); md5thusfar[32] = '\0'; Note the last line, if file[0] is 32 or more characters long then md5thusfar won't finish with a null, so trouble will ensue. That's all of the problems I can see in authprocess.c at the moment. If you fix those problems you should be in with a much better shot of getting it to work. Regards, Richard PS: As a formatting point when you have something like: <tab>func(first_arg, <tab> second_arg); You shouldn't change it to <tab>func(first_arg, <tab><tab>second_arg); As the arguments won't line up if someone is using different sized tab stops. You should always tab to specify indents and space to line up a command the spreads multiple lines. The same applies for if/while conditions and for statements. PPS: I've made you an admin of the sourceforge project. -----Original Message----- From: Andrew McGlashan [mailto:ae...@bi...] Sent: Thursday, 9 May 2002 10:45 AM To: Harris, Richard Cc: Bill Lucas; Mario Piazzese Subject: Fw: SEWL passwdsecure -- other note Importance: High Richard, I have made this email high priority as SE Water has a number of uses that will need to use the passwdsecure tool. Bill has even suggested that I be listed as a maintainer to try to progress this quicker; I would really like some more help. Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK works. I have since re-worked that but I still have some problems. The FILEICMP looks okay after all, although I haven't actually tested it; I didn't look at it closely enough to understand it before. The problem I am having now with the re-worked FILECMP / MD5CHECK section having been done has to do with the getPsinfo function; it is dropping out without completing all checks. I don't know why it dumps out, but here is the statement that is failing: sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, fileinfo); Other information (from the non-Linux code): > Checking file types / sizes... > > int sizeRead /* always 336 if successful */ > int sizeReadTotal /* always 0 */ > > > unsigned char buf[sizeof(psinfo_t)] > Now it fails after a number of iterations. I did remove a single check from one require group and it got through to an additional require group. I was going to include the output file with the debug information, but I don't have it with me right now. Let me know if you need it and I will endeavour to get it to you. I did adjust the following in the getPsinfo function: from FILE* fileinfo; to FILE *fileinfo; I assume that was simply a typo. The change didn't help or seem to effect anything. I also made sure that every fopen had an fclose; I thought that maybe there were too many files open or something like that. Maybe there is still something in this as it was quite late when I packed it in last night. The Makefile in the attached source has a DEBUG entry added to the CFLAGS line, so it always makes the debug version for now. My 'do_conf' doesn't include the MD5 directory, however, it uses the found OpenSSL libraries and thus the configure defines USE_MD5. AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: <And...@se...> To: <ae...@bi...> Sent: Thursday, May 09, 2002 1:12 AM Subject: SEWL passwdsecure -- other note > > The following statement fails consistently for unknown reasons....., > but only after so many reads... > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > > Checking file types / sizes... > > int sizeRead /* always 336 if successful */ > int sizeReadTotal /* always 0 */ > > > unsigned char buf[sizeof(psinfo_t)] > *********************************************************************************** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. *********************************************************************************** |
From: Harris, R. <ha...@ta...> - 2002-05-09 02:02:49
|
Andrew, To become an admin go to http://sourceforge.net/account/register.php and create yourself an account. I'll add you to the project and give you admin privilages. To truss it probably won't be as easy as replacing passwdsecure.debug with a shell script as that will break your rules if there is an extra shell script and a truss call in the program chain. What might be easier is to add a sleep at the start of passwdsecure.debug so you can work out what the pid is by doing a "ps -ef" and then call "truss -f -p PID" from another window. Richard -----Original Message----- From: Andrew McGlashan [mailto:ae...@bi...] Sent: Thursday, 9 May 2002 11:31 AM To: Harris, Richard Cc: Bill Lucas; Mario Piazzese; pas...@li... Subject: Re: SEWL passwdsecure -- other note Richard, I wouldn't mind being a maintainer; is there some further info on how this works? I have a fprintf immediately before the read and immediately after, only the former prints when the program drops out. I will have a look at using truss to get some more info; it will not be trivial to set it up with my current rules in place though; I might be able to do this with a simple shell script replacing my 'passwdsecure.debug' and calling a new name for the actual passwdsecure program. AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: "Harris, Richard" <ha...@ta...> To: "'Andrew McGlashan'" <ae...@bi...>; "Harris, Richard" <ha...@ta...> Cc: "Bill Lucas" <bil...@se...>; "Mario Piazzese" <Mar...@se...>; <pas...@li...> Sent: Thursday, May 09, 2002 11:11 AM Subject: RE: SEWL passwdsecure -- other note > Hi Andrew, > > Responses in line. > > Richard. > > -----Original Message----- > From: Andrew McGlashan [mailto:ae...@bi...] > Sent: Thursday, 9 May 2002 10:45 AM > To: Harris, Richard > Cc: Bill Lucas; Mario Piazzese > Subject: Fw: SEWL passwdsecure -- other note > Importance: High > > > Richard, > > I have made this email high priority as SE Water has a number of uses that > will need to use the passwdsecure tool. Bill has even suggested that I be > listed as a maintainer to try to progress this quicker; I would really like > some more help. > > <<< > > I haven't got a problem making you a maintainer if you want. > > >>> > > Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK > works. I have since re-worked that but I still have some problems. The > FILEICMP looks okay after all, although I haven't actually tested it; I > didn't look at it closely enough to understand it before. > > The problem I am having now with the re-worked FILECMP / MD5CHECK section > having been done has to do with the getPsinfo function; it is dropping out > without completing all checks. I don't know why it dumps out, but here is > the statement that is failing: > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > Other information (from the non-Linux code): > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > Now it fails after a number of iterations. I did remove a single check from > one require group and it got through to an additional require group. I was > going to include the output file with the debug information, but I don't > have it with me right now. Let me know if you need it and I will endeavour > to get it to you. > > <<< > > When you say it fails, do you mean it crashes or it fails to read the info? > > I think I might need the debug info to get a better picture of what is going > on. > > >>> > > I did adjust the following in the getPsinfo function: > from FILE* fileinfo; > to FILE *fileinfo; > I assume that was simply a typo. > > <<< > In general you should always use > FILE* fileinfo; > rather than > FILE *fileinfo; > as it seperates the type from the variable name. The type is FILE* (a > pointer to a FILE) and the variable is fileinfo. This distinction is > not as clear in the second instance. They both compile to the same > code but most modern style guides will recomend you use the first version. > >>> > > > The change didn't help or seem to effect > anything. I also made sure that every fopen had an fclose; I thought that > maybe there were too many files open or something like that. Maybe there is > still something in this as it was quite late when I packed it in last night. > > <<< > > I was thinking that also, but it doesn't seem to be the case. The ideal > solution would be to "truss" the process (solaris command that traces > system calls) but this may be non-trivial as it will require a special > configuration file that lets the passwdsecure command be called from. > > If we could get the truss output that would probably point us in the > right direction. > > >>> > > The Makefile in the attached source has a DEBUG entry added to the CFLAGS > line, so it always makes the debug version for now. My 'do_conf' doesn't > include the MD5 directory, however, it uses the found OpenSSL libraries and > thus the configure defines USE_MD5. > > AndrewM > > Andrew McGlashan AACS > Director > > Mobile: 04 2574 1827 > > Affinity Vision Australia Pty Ltd > ABN 91 099 273 855 > > This message contains privileged and confidential information intended only > for the use of the addressee named above. If you are not the intended > recipient of this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. If you have > received this message in error please notify Affinity Vision Australia Pty > Ltd at ae...@bi... Any views expressed in this message are those of the > individual sender, except where the sender specifically states them to be > the views of Affinity Vision Australia Pty Ltd > > ----- Original Message ----- > From: <And...@se...> > To: <ae...@bi...> > Sent: Thursday, May 09, 2002 1:12 AM > Subject: SEWL passwdsecure -- other note > > > > > > The following statement fails consistently for unknown reasons....., > > but only after so many reads... > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > fileinfo); > > > > > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > **************************************************************************** ******* > The information in this e-mail message and any files transmitted with it > are intended to be confidential and for the use of only the individual or > entity to whom they are addressed. The message and files may be > protected by legal professional privilege, or other legal rules. The > confidentiality of and privilege applying to this message and > files is not waived if this message or files has been sent to you by mistake. > If the reader of this message or files is not the intended recipient, you are > notified that retention, distribution or copying of this message and files are > strictly prohibited. If you receive this message or files in error, please > notify us immediately by telephone or return e-mail and delete all copies > from your computer system. It is the recipient's responsibility to check this > message and files for viruses. > > Thank you. > **************************************************************************** ******* > > ******************************************************* PLEASE NOTE: This internet email message has been checked for viruses and appropriate content to ensure it complies with TABCORP's electronic communication policy. ******************************************************* *********************************************************************************** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. *********************************************************************************** |
From: Andrew M. <ae...@bi...> - 2002-05-09 01:35:46
|
Richard, I wouldn't mind being a maintainer; is there some further info on how this works? I have a fprintf immediately before the read and immediately after, only the former prints when the program drops out. I will have a look at using truss to get some more info; it will not be trivial to set it up with my current rules in place though; I might be able to do this with a simple shell script replacing my 'passwdsecure.debug' and calling a new name for the actual passwdsecure program. AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: "Harris, Richard" <ha...@ta...> To: "'Andrew McGlashan'" <ae...@bi...>; "Harris, Richard" <ha...@ta...> Cc: "Bill Lucas" <bil...@se...>; "Mario Piazzese" <Mar...@se...>; <pas...@li...> Sent: Thursday, May 09, 2002 11:11 AM Subject: RE: SEWL passwdsecure -- other note > Hi Andrew, > > Responses in line. > > Richard. > > -----Original Message----- > From: Andrew McGlashan [mailto:ae...@bi...] > Sent: Thursday, 9 May 2002 10:45 AM > To: Harris, Richard > Cc: Bill Lucas; Mario Piazzese > Subject: Fw: SEWL passwdsecure -- other note > Importance: High > > > Richard, > > I have made this email high priority as SE Water has a number of uses that > will need to use the passwdsecure tool. Bill has even suggested that I be > listed as a maintainer to try to progress this quicker; I would really like > some more help. > > <<< > > I haven't got a problem making you a maintainer if you want. > > >>> > > Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK > works. I have since re-worked that but I still have some problems. The > FILEICMP looks okay after all, although I haven't actually tested it; I > didn't look at it closely enough to understand it before. > > The problem I am having now with the re-worked FILECMP / MD5CHECK section > having been done has to do with the getPsinfo function; it is dropping out > without completing all checks. I don't know why it dumps out, but here is > the statement that is failing: > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > Other information (from the non-Linux code): > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > Now it fails after a number of iterations. I did remove a single check from > one require group and it got through to an additional require group. I was > going to include the output file with the debug information, but I don't > have it with me right now. Let me know if you need it and I will endeavour > to get it to you. > > <<< > > When you say it fails, do you mean it crashes or it fails to read the info? > > I think I might need the debug info to get a better picture of what is going > on. > > >>> > > I did adjust the following in the getPsinfo function: > from FILE* fileinfo; > to FILE *fileinfo; > I assume that was simply a typo. > > <<< > In general you should always use > FILE* fileinfo; > rather than > FILE *fileinfo; > as it seperates the type from the variable name. The type is FILE* (a > pointer to a FILE) and the variable is fileinfo. This distinction is > not as clear in the second instance. They both compile to the same > code but most modern style guides will recomend you use the first version. > >>> > > > The change didn't help or seem to effect > anything. I also made sure that every fopen had an fclose; I thought that > maybe there were too many files open or something like that. Maybe there is > still something in this as it was quite late when I packed it in last night. > > <<< > > I was thinking that also, but it doesn't seem to be the case. The ideal > solution would be to "truss" the process (solaris command that traces > system calls) but this may be non-trivial as it will require a special > configuration file that lets the passwdsecure command be called from. > > If we could get the truss output that would probably point us in the > right direction. > > >>> > > The Makefile in the attached source has a DEBUG entry added to the CFLAGS > line, so it always makes the debug version for now. My 'do_conf' doesn't > include the MD5 directory, however, it uses the found OpenSSL libraries and > thus the configure defines USE_MD5. > > AndrewM > > Andrew McGlashan AACS > Director > > Mobile: 04 2574 1827 > > Affinity Vision Australia Pty Ltd > ABN 91 099 273 855 > > This message contains privileged and confidential information intended only > for the use of the addressee named above. If you are not the intended > recipient of this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. If you have > received this message in error please notify Affinity Vision Australia Pty > Ltd at ae...@bi... Any views expressed in this message are those of the > individual sender, except where the sender specifically states them to be > the views of Affinity Vision Australia Pty Ltd > > ----- Original Message ----- > From: <And...@se...> > To: <ae...@bi...> > Sent: Thursday, May 09, 2002 1:12 AM > Subject: SEWL passwdsecure -- other note > > > > > > The following statement fails consistently for unknown reasons....., > > but only after so many reads... > > > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > > fileinfo); > > > > > > Checking file types / sizes... > > > > int sizeRead /* always 336 if successful */ > > int sizeReadTotal /* always 0 */ > > > > > > unsigned char buf[sizeof(psinfo_t)] > > > > > **************************************************************************** ******* > The information in this e-mail message and any files transmitted with it > are intended to be confidential and for the use of only the individual or > entity to whom they are addressed. The message and files may be > protected by legal professional privilege, or other legal rules. The > confidentiality of and privilege applying to this message and > files is not waived if this message or files has been sent to you by mistake. > If the reader of this message or files is not the intended recipient, you are > notified that retention, distribution or copying of this message and files are > strictly prohibited. If you receive this message or files in error, please > notify us immediately by telephone or return e-mail and delete all copies > from your computer system. It is the recipient's responsibility to check this > message and files for viruses. > > Thank you. > **************************************************************************** ******* > > |
From: Harris, R. <ha...@ta...> - 2002-05-09 01:19:13
|
Hi Andrew, Responses in line. Richard. -----Original Message----- From: Andrew McGlashan [mailto:ae...@bi...] Sent: Thursday, 9 May 2002 10:45 AM To: Harris, Richard Cc: Bill Lucas; Mario Piazzese Subject: Fw: SEWL passwdsecure -- other note Importance: High Richard, I have made this email high priority as SE Water has a number of uses that will need to use the passwdsecure tool. Bill has even suggested that I be listed as a maintainer to try to progress this quicker; I would really like some more help. <<< I haven't got a problem making you a maintainer if you want. >>> Okay, I have looked at FILECMP again -- I broke it with my former MD5CHECK works. I have since re-worked that but I still have some problems. The FILEICMP looks okay after all, although I haven't actually tested it; I didn't look at it closely enough to understand it before. The problem I am having now with the re-worked FILECMP / MD5CHECK section having been done has to do with the getPsinfo function; it is dropping out without completing all checks. I don't know why it dumps out, but here is the statement that is failing: sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, fileinfo); Other information (from the non-Linux code): > Checking file types / sizes... > > int sizeRead /* always 336 if successful */ > int sizeReadTotal /* always 0 */ > > > unsigned char buf[sizeof(psinfo_t)] > Now it fails after a number of iterations. I did remove a single check from one require group and it got through to an additional require group. I was going to include the output file with the debug information, but I don't have it with me right now. Let me know if you need it and I will endeavour to get it to you. <<< When you say it fails, do you mean it crashes or it fails to read the info? I think I might need the debug info to get a better picture of what is going on. >>> I did adjust the following in the getPsinfo function: from FILE* fileinfo; to FILE *fileinfo; I assume that was simply a typo. <<< In general you should always use FILE* fileinfo; rather than FILE *fileinfo; as it seperates the type from the variable name. The type is FILE* (a pointer to a FILE) and the variable is fileinfo. This distinction is not as clear in the second instance. They both compile to the same code but most modern style guides will recomend you use the first version. >>> The change didn't help or seem to effect anything. I also made sure that every fopen had an fclose; I thought that maybe there were too many files open or something like that. Maybe there is still something in this as it was quite late when I packed it in last night. <<< I was thinking that also, but it doesn't seem to be the case. The ideal solution would be to "truss" the process (solaris command that traces system calls) but this may be non-trivial as it will require a special configuration file that lets the passwdsecure command be called from. If we could get the truss output that would probably point us in the right direction. >>> The Makefile in the attached source has a DEBUG entry added to the CFLAGS line, so it always makes the debug version for now. My 'do_conf' doesn't include the MD5 directory, however, it uses the found OpenSSL libraries and thus the configure defines USE_MD5. AndrewM Andrew McGlashan AACS Director Mobile: 04 2574 1827 Affinity Vision Australia Pty Ltd ABN 91 099 273 855 This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Affinity Vision Australia Pty Ltd at ae...@bi... Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Affinity Vision Australia Pty Ltd ----- Original Message ----- From: <And...@se...> To: <ae...@bi...> Sent: Thursday, May 09, 2002 1:12 AM Subject: SEWL passwdsecure -- other note > > The following statement fails consistently for unknown reasons....., > but only after so many reads... > > sizeRead = fread(buf+sizeReadTotal, 1, sizeof(psinfo_t)-sizeReadTotal, > fileinfo); > > > Checking file types / sizes... > > int sizeRead /* always 336 if successful */ > int sizeReadTotal /* always 0 */ > > > unsigned char buf[sizeof(psinfo_t)] > *********************************************************************************** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. *********************************************************************************** |
From: Harris, R. <ha...@ta...> - 2002-05-07 00:20:48
|
Hi Andrew, -----Original Message----- From: And...@se... [mailto:And...@se...] Sent: Monday, 6 May 2002 7:22 PM To: ha...@ta... Cc: Mar...@se... Subject: RE: passwdsecure -- Updated Word document. Richard, Thanks for your reply. Here is my latest response. Sorry for not getting back to you sooner, but I have been very busy. 1. It seems legitimate to me that you can currently test for each of: FILENAME, CMNDLINE and MD5CHECK -- if all are Okay, then we can go ahead. <<< It isn't really OK just to check for those values as they can all be spoofed if you can't confirm what the program running really is. If I ran my own program I could spoof the FILENAME and CMNDLINE to match the criteria and then you would be doing a MD5CHECK on a file I'm not actually running. You need to do a FILECMP, FILEICMP or a MD5CHECK on /proc/%p/object/a.out to verify that the program you want is really running. >>> 2. CMNDLINE -- yes, that would be great. It would allow for re-use of tools with more ease. The following shell script has many possible command line options, therefore, a regular expression check would be great. /u00/app/oracle/admin/local/unix/alldb.sh=20 This particular shell script can either run SQL or a shell script against all databases, -- each SQL script might have a different name, ditto the shell scripts; there are also options for running on local SIDs and / or remote SIDs. <<< I'll have a look at this when I get a chance. >>> 3. I used two versions of passwdsecure, one for debugging. Checking the FILENAME, CMDLINE and MD5CHECK all seem valid to me. <<< They'll work fine on a valid command, they just may not pick it up if someone is spoofing the command line. >>> 4. FILECMP and FILEICMP do not seem to work at all, am I missing something? It looks to me as though processing for these has been omitted and it simply falls into the md5 area of readconfig.c <<< Can you give me some more idea of what is happening here? The FILECMP won't work unless you've got MD5 compiled in, but I'm guessing you have because you mentioned using MD5CHECK. FILEICMP should work in all cases. >>> 5. Dynamically sized strings -- I don't know of any benefit to this, I think it is important to cater for worst case string sizes, i.e. as big as can reasonably be expected to be in use. I suppose buffer overflow vulnerabilities should be addressed and if it helps to make the strings dynamically sized, well go for it. Regards AndrewM <<< Richard. PS: This discussion should probably be taking place on pas...@li.... You can subscribe at: http://lists.sourceforge.net/lists/listinfo/passwdsecure-devel >>> -----Original Message----- From: Harris, Richard [mailto:ha...@ta...] Sent: Wednesday, 24 April 2002 12:53 PM To: 'And...@se...' Subject: RE: passwdsecure -- Updated Word document. Hi Andrew, I'm afraid I've moved sites since you sent your original update to passwdsecure so if you could send that again that would be handy. Was it just updates to readconfig.c? I've made comments about the document you sent inline. Richard > Passwdsecure > Some further code changes were required to increase buffer sizes in the readconfig.c=20 > program. >=20 > Issues > There are some problems that need to be considered when setting up a passwdsecure.conf=20 > file:: > 1. Although you can do md5 checks against files, it is not easy to ensure that the file=20 > you checked against is the file that the user process is running; True. > 2. The FILENAME data is limited to 15 characters of a filename and does not include any=20 > path component (also, shebang lines are needed for shell scripts in order to be able to=20 > properly identify the file name); The FILENAME parameter is probably of lilited use in verifying the process, I only included it for completeness. > 3. The CMDLINE line component can specify the appropriate paths with file names, but this=20 > can get quite long when including many options; use of command line parameters makes=20 > processing difficult, if not impossible. The CMDLINE data is limited to 80 characters per=20 > entry. Given that the passwdsecure mechanism is only effective from a controlled calling environment I would have thought you would know what possible command lines could be used. > 4. A set of passwords cannot be re-used for multiple access paths; each path =91tree=92 needs=20 > it=92s own set of passwords. That functionality can be provided using ONEOF (like you've done in [oracle_par1]) or were you meaning something else? > 5. If a shell script backgrounds a job, as follows =91nohup do_something > x.x 2>&1 &=92 --=20 > then the relationship b/w the calling program and the called program is lost (root takes=20 > ownership of the nohup job). That's true. Once a job has been nohup'ed I can't think of a secure way of verifying that it is a process you want to give the password to. > In order to solve the problem with md5 checks, you need to ensure that the FILENAME and=20 > the CMNDLINE is catered for specifically =96 this will ensure that the correct md5 checked=20 > file is actually the same file that the user process runs with. I'm not exactly sure what you mean by this. Do you mean that passwdsecure should parse the commandline and know about various script interperators (like sh, perl and awk) and determine the script file name from the command line? > If a program that you are checking has a CMDLINE with parameters, then it is difficult to=20 > check all possible combinations. An alternative would be to setup appropriate environment=20 > variables and this is done with wd.sh using WD_USER and WD_SID environment variables for=20 > finding the password of the particular Oracle account. I'm not sure what wd.sh is supposed to do. Based on the config extract provided I'm guessing that it is used as a central resource to call passwdsecure. If you want to pass the information using environment variables that's fine. > I did try creating temporary files in /tmp using a $TEMP_PID environment variable to link=20 > the programs. This was an attempt to ensure that the actual required program that is=20 > trusted is the one that is running without having many CMDLINE options. > Implementation with the wd.sh program required the setting of the environment variable $_ > to see what the actual program name with path is. The wd.sh program set up parameters > and then called another shell script which checked the source program by comparing $_ with > the correct filename and path, it then reads the parameters to continue. The $_ variable > can be spoofed, so this turned out to not be a good solution, but it almost worked well. =20 > The ONLY safe way to proceed is to have no programs receiving parameters, that way, the=20 > files and paths and md5 check sums can all be checked fairly easily. Once you start=20 > adding parameters, you could cause a blow out in the use of ONEOF:CMDLINE entries. Maybe there needs to be a CMDLINERE that lets you have a regular expression for the command line. Will this resolve the problem? > Sample passwdsecure.conf file without the passwords section. >=20 >=20 > [oracle_wd] > UID:oracle > ONEOF:FILENAME:passwdsecure,FILENAME:passwdsecure.de > PARENT:oracle_par1 > #cannot check commandline as ther would be too many combinations, at least for oracle. This is the current process so checking the command line is a bit redundant, we know passwdsecure has been called because it's running. Really only parent is required. > [oracle_par1] > UID:oracle > FILENAME:wd.sh > CMDLINE:/bin/sh /u00/app/oracle/local/unix/wd.sh > ONEOF:PARENT:oracle_coal,PARENT:oracle_coal2,PARENT:oracle_chkb,PARENT:oracl e_alldb,PARENT> :oracle_conf2,PARENT:oracle_ii,PARENT:orad > MD5CHECK:13b82c49fefdcdeb16c239ebdeaa6039,/u00/app/oracle/local/unix/wd.sh This is reasonably easy to spoof. I could write a program that calls: execl("/home/baduser/wd.sh", "/bin/sh", "/u00/app/oracle/local/unix/wd.sh"); Where /home/baduser/wd.sh is a program of mine that calls passwdsecure and does bad things with the password. You would have to do this a couple of times to satisfy the parent requirement. What you also need is a line specifying that the program running is infact /bin/sh: FILEICMP:/proc/%p/object/a.out,/bin/sh >=20 > [oracle_coal] > FILENAME:coalesce.backup > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/coalesce.backup_ctl.sh > MD5CHECK:0d35ac61ec6da16a66cc5dcefa9c5e92,/u00/app/oracle/amcglashan/coalesc e.backup_ctl.sh >=20 > [oracle_coal2] > FILENAME:coalesce.backup > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/coalesce.backup_ctl2.sh > MD5CHECK:e8f93297e83e3d6a0f53aca3faf77729,/u00/app/oracle/amcglashan/coalesc e.backup_ctl2.sh >=20 > [oracle_chkb] > FILENAME:chk_backup.sh > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/chk_backup.sh > MD5CHECK:ad522be893bfe77fe1f9b398d37eca4f,/u00/app/oracle/amcglashan/chk_bac kup.sh >=20 > [oracle_alldb] > FILENAME:alldb.sh > ONEOF:CMDLINE:/bin/ksh /u00/app/oracle/local/unix/alldb.sh -fallstat7 -tp -p/u00/app/oracle/l,CMDLINE:/bin/ksh /u00/app/oracle/local > MD5CHECK:f1f643cdce4afdaff18de57ffcf3b87d,/u00/app/oracle/local/unix/alldb.s h >=20 > [oracle_conf2] > FILENAME:config2.sh > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/sewl.config/config2.sh > MD5CHECK:acb14a807ce94aed63922e9a34e5667b,/u00/app/oracle/amcglashan/sewl.co nfig/config2.sh >=20 > [oracle_ii] > FILENAME:instance_info.s > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/sewl.config/instance_info.sh > MD5CHECK:12ec432ece46a4efeea70d599801ec1d,/u00/app/oracle/amcglashan/sewl.co nfig/instance_info.sh >=20 > [oracle_uri] > FILENAME:user_role_info. > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/sewl.config/user_role_info.sh > MD5CHECK:817313031922d154317c8768837a80f2,/u00/app/oracle/amcglashan/sewl.co nfig/user_role_info.sh >=20 > [oracle_orasid] > FILENAME:ora_sid2.sh > CMDLINE:/bin/sh /u00/app/oracle/amcglashan/sewl.config/ora_sid2.sh > MD5CHECK:c62724e45bcfe3885561a8651a57a917,/u00/app/oracle/amcglashan/sewl.co nfig/ora_sid2.sh >=20 Again, for all of these you need a FILEICMP to verify that it is really running /bin/sh. >=20 > Files changed on ocean server > The following files were changed on the ocean server during testing of the functionality > of the new =91wd.sh=92 process: > /u00/app/oracle/local/unix/wd.sh > This file no longer relies on /u00/app/oracle/local/config/`uname =96n`/wd it now relies on > /usr/local/src/aem/etc/passwdsecure.conf >=20 > /u00/app/oracle/amcglashan/chk_backup.sh > This file simply checks database data file backup status. >=20 > /u00/app/oracle/amcglashan/coalesce.backup_ctl.sh > This file does creates a trace file that can be used to re-create a database controlfile,=20 > it then coalesces tablespaces. >=20 > /u00/app/oracle/local/unix/alldb.sh > This file runs scripts against databases in a bulk manner. The script could be a SQL > script or a shell script. >=20 > /u00/app/oracle/amcglashan/sewl.config/ -- various files >=20 > Debug Option > The code of wd.sh checks for an environment variable DEBUG_PASSWDSECURE, if this is set,=20 > then the /usr/local/src/aem/sbin/passwdsecure.debug. program is used. Otherwise, the=20 > non-debug version runs /usr/local/src/aem/sbin/passwdsecure =96 the difference between=20 > these two programs is due to a simple compile time setting. >=20 > With the debugging version, you can see the parsed passwdsecure.conf entries and you can=20 > see the attempts to validate each section. Output from =91ps =96fe=92 fo= r the current process=20 > is shown as well. This allows you to see exactly what the values of FILENAME, and CMDLINE=20 > are set to and you can therefore make the correct entries in the passwdsecure.conf file=20 > much more easily. >=20 > Further Code Changes > Further code changes to readconfig.c program source: > 1. Adjusted buffer size for line lengths up to 1023 characters when reading the=20 > passwdsecure.conf file (was reading only up to 511 characters). > 2. Max Elements up from 256 to 1024. > 3. Various other entries increased from 256 to 1024, fgets change from 511 to 1023 for=20 > read of config lines from passwdsecure.conf file. I think I have to look at some mechinism of using dynamically sized strings. Let me know of any feedback yoy have. Regards, Richard **************************************************************************** ******* The information in this e-mail message and any files transmitted with it=20 are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The=20 confidentiality of and privilege applying to this message and=20 files is not waived if this message or files has been sent to you by mistake.=20 If the reader of this message or files is not the intended recipient, you are=20 notified that retention, distribution or copying of this message and files are=20 strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this=20 message and files for viruses. Thank you. **************************************************************************** ******* ********************************************************************** Information contained in this e-mail, including accompanying documents, is intended for use of the addressee only. If=20 you are not the intended recipient, please notify the sender as soon as possible and delete the e-mail. If you are not the intended recipient, you may not distribute, copy, act upon, retain or otherwise use this e-mail or information contained here. The confidential and possibly privileged=20 nature of the information contained in this e-mail is not waived by reason of mistaken delivery to other than the intended recipient. Your use or reproduction of this e-mail and accompanying documents may also breach South East Water Limited's copyright. ********************************************************************** South East Water Limited http://www.sewl.com.au ******************************************************* PLEASE NOTE: This internet email message has been checked for viruses and appropriate content to ensure it complies with TABCORP's electronic communication policy. ******************************************************* ***************************************************************************= ******** The information in this e-mail message and any files transmitted with it=20 are intended to be confidential and for the use of only the individual or= entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The=20 confidentiality of and privilege applying to this message and=20 files is not waived if this message or files has been sent to you by mistak= e.=20 If the reader of this message or files is not the intended recipient, you a= re=20 notified that retention, distribution or copying of this message and files = are=20 strictly prohibited. If you receive this message or files in error, please= notify us immediately by telephone or return e-mail and delete all copies= from your computer system. It is the recipient's responsibility to check t= his=20 message and files for viruses. Thank you. ***************************************************************************= ******** |