Re: Warning message about /boot/System.map-2.2.19
On Wed, Jun 13, 2001 at 09:01:59AM +0200, Physicman wrote: Hi, I've also encountered this problem when running a ps after recompiling a brand new kernel. Apparently, ps (and probably other applications) try to fetch the System.map in / so if you just symlink it to the new System.map file it should solve the issue. Feel free not to send your reply to debian-security if my problem is not no. there is no need for symlinks to any System.map. just make sure there are no symlinks and that you always name your System.map System.map-`uname -r` it should be in /boot. using kernel package takes care of all this correctly -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Kernel 2.4 SOS
Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. I have pointed apt to sid but it wants to pull packages down from woody. Now what i need to know, is woody stable enough for a proxy/firewall machine ? Thanks Craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, 13 Jun 2001, Craig wrote: I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. You don't need to install a full woody system to run a 2.4.x kernel. I administer a large number of potato boxen and just picked the necessary source packages from unstable and recompiled them, with very minor changes to satisfy some different dependencies due to files that belong to different packages between unstable and potato. There are a few sites that make available the needed precompiled packages for potato, if you don't want to do it yourself. Look at http://www.fs.tum.de/~bunk/kernel-24.html and people.debian.org/~bunk/debian. I migh also let you have the debs I recompiled, but I would not trust them if I were in your shoes... :) Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 10:48:22AM +0200, Craig wrote: Now what i need to know, is woody stable enough for a proxy/firewall machine I do not know the answer to this as I haven't really used woody yet. But, the stuff you need to make it work smoothly on a potato box can be found starting from here: http://www.debian.org/News/2001/20010415 Fwiw, I had no problems at all using a 2.4 kernel on a regular potato box without the updates mentioned at that link, the only exception was that the old version of modprobe couldn't load any 2.4 modules. So you could: a) update to the modutils package included in the updates above; b) build all your drivers statically into the kernel, thereby not needing modutils; c) write some 'insmod' lines into your scripts to load modules, the old insmod still works fine (and is what I did). HTH. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Kernel 2.4 SOS
Title: RE: Kernel 2.4 SOS Now what i need to know, is woody stable enough for a proxy/firewall machine Just take the packages you need to run 2.4-kernel from woody and continue use potato. That's what i do, works perfect. And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
Re: Kernel 2.4 SOS
Hi Craig, Now what i need to know, is woody stable enough for a proxy/firewall machine ...no prob at all, woody is nearly stable and i use it since half a year without any probs as a firewall/squid-proxy and as a productive system (intranet-server) for 20 users. for sure these are two different maschines :-) regards joris -- SBF Gruppe - http://www.sbf.de Steinhof 51 - D-40699 Erkrath Tel: +49 211 20 99 51 0 Fax: +49 211 20 99 51 88 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 11:01:10AM +0200, Johan Segernäs wrote: And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. woody also does not get security updates, in fact it can take a very long time for security related updates to get into woody since its almost entirely managed by a script. unstable simply gets new versions of a package installed immediatly so any security fixes are in unstable as soon as they are packaged. that does NOT guarentee they will make it into woody any time soon though. the `testing' distribution (now woody) is the least secure branch you can run. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
RE: Kernel 2.4 SOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! as Giacomo already mailed, you have the possibility to use Adrian's packages from people.debian.org/~bunk/debian. But I had several problems with them using isdn and proxy, etc. I have woody installed on my router/firewall/proxy/fax-server. It's working pretty fine. I have uptimes of over 50 days, only interruped by installing new kernels. I would say woody is quite stable enough for a router, if you can handle some basic problems, which still occour in woody time by time. Michael I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. I have pointed apt to sid but it wants to pull packages down from woody. Now what i need to know, is woody stable enough for a proxy/firewall machine ? Thanks Craig -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOycwmgUqVktPGYHYEQKmxwCg0VqT8BGX249XMCALjerSycqQ7lkAnR3A N7YCfrw0hnyKEsnDSkFmeaED =JRio -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
Ethan Benson wrote: On Wed, Jun 13, 2001 at 11:01:10AM +0200, Johan Segernäs wrote: And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. woody also does not get security updates, in fact it can take a very long time for security related updates to get into woody since its almost entirely managed by a script. unstable simply gets new versions of a package installed immediatly so any security fixes are in unstable as soon as they are packaged. that does NOT guarentee they will make it into woody any time soon though. the `testing' distribution (now woody) is the least secure branch you can run. ...this is a thing where i can't agree, in the last 6 month, all security-fixes were as soon implemented as in potato (i have both, so i'd compared). e.g. bind probs, man-db probs for mention a few. but i have also the security-link in my sources.list even under woody, maybe this is the reason why it works. regards joris -- SBF Gruppe - http://www.sbf.de Steinhof 51 - D-40699 Erkrath Tel: +49 211 20 99 51 0 Fax: +49 211 20 99 51 88 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 12:21:44PM +0200, Joris Mocka wrote: ...this is a thing where i can't agree, in the last 6 month, all security-fixes were as soon implemented as in potato (i have both, so i'd compared). e.g. bind probs, man-db probs for mention a few. but i have also the security-link in my sources.list even under woody, maybe this is the reason why it works. security.debian.org is only for stable, it won't work on woody or unstable since they almost invariably have newer versions then what goes in security.debian.org. the fact you have so far seen good results with security is mostly chance. if a security fix has some dependency issue, or bug reports, it won't go in unless forced. there is nothing guarenteeing fixes will go in and there is a good chance they won't. there isn't a security team for anything but stable. beware. of course the same goes for unstable, if you use any branch other then stable you are responsible for checking that security fixes are getting made and installed, there won't be an advisory. -- Ethan Benson http://www.alaska.net/~erbenson/ PGP signature
Re: Creating a logfile for Netfilter
On Mon, Jun 11, 2001 at 07:11:00PM +0100, Tim Haynes wrote: Stefan Srdic [EMAIL PROTECTED] writes: Anyway, as you can guess I am using netfilter for firewalling. How can I pipe all logs from Netfilter into a single logfile? Lets say I wanted all log messages from netfilter to be loged into /var/log/netfilter. How could I accomplish that? FWIW, my approach: assert a log-prefix in your logging iptables rules, and install syslog-ng with a regexp match to pick up your prefix (make it distinctive, eg 'Catch-all: .*IN=.*OUT=' would probably be precise enough). Here is an alternative approach which I took. I think it is a little easier. If you create a user defined chain something like the following: iptables -N log_droped iptables -A log_droped -j LOG --log-level 1 --log-prefix droped_:: iptables -A log_droped -j DROP And make all your firewall rules that need to be dropped -j (jump) to this chain then they will be logged at log-level 1 (Alert). Then, if you edit /etc/syslog.conf and append the following line: kern.=alert -/var/log/firewall.log (Nb. line up with tabs) Then syslog will log all logs at level alert to the separate file. Not much else gets logged at level alert so it should be OK and not upset other logging. Thus, the firewall will log to /var/log/firewall.log - just create this file with touch. Hth. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 12:21:44PM +0200, Joris Mocka wrote: Ethan Benson wrote: On Wed, Jun 13, 2001 at 11:01:10AM +0200, Johan Segernäs wrote: And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. woody also does not get security updates, in fact it can take a very long time for security related updates to get into woody since its almost entirely managed by a script. unstable simply gets new versions of a package installed immediatly so any security fixes are in unstable as soon as they are packaged. that does NOT guarentee they will make it into woody any time soon though. the `testing' distribution (now woody) is the least secure branch you can run. ...this is a thing where i can't agree, in the last 6 month, all security-fixes were as soon implemented as in potato (i have both, so i'd compared). e.g. bind probs, man-db probs for mention a few. but i have also the security-link in my sources.list even under woody, maybe this is the reason why it works. What is the security link? Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 03:35:29AM -0800, Ethan Benson wrote: On Wed, Jun 13, 2001 at 08:52:24PM +1000, [EMAIL PROTECTED] wrote: What is the security link? deb http://security.debian.org/debian-security/ stable/updates main contrib note that says stable. there is no security link for woody/testing or unstable. they do not get security updates from the security team. OK, I thought that was the case. Thanks. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel 2.4 SOS
Craig wrote: Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. Does kernel 2.4 have some special feature of port forwarding that the 2.2.x kernels don't have? I don't see why mess with 2.4 at all when kernel 2.2.17 (potato rev0) or higher will handle port forwarding just fine. And by just using potato, you can keep up with the security updates easier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
Miquel Mart?n L?pez escribió: Hi all! We have several vt-100 terminal that log to the naub server at our office. Still, some users without account in the main server would like to login to another machine, so I was planning on creating a passwordless acount with a shell that's a program that asks for usernames and then execs ssh -l username. I didn't want to do a script to avouid ppl hitting ctrl+c and having a passwordless account. I'm also worried about buffer-overflows and a miriad things I'm too newbie to understand, so I'd appreciate any comments on the security flaws you see on this: Umm.. programs can have security flaws. How about using port redirection, a similar problem arised to a group of administrators I belong to and someon proposed, using port redirection, the following: iptables -t nat -A PREROUTING -p tcp --dport -j DNAT --to another_server:22 That way you do not depend on (sometimes unreliable) programs/daemons. Of course, you needed, Linux 2.4. Another solution would be to use applications such as (quick look to apt-cache search redirect) redir or rinetd.. Javi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
charname[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
char name[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
--
dg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
Thanks for the feedback, I'll respond to both your replies at once.
On Wed, Jun 13, 2001 at 08:24:32PM +0400, Daniel Ginsburg [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
{
charname[21]; /* Should be macro (#define NAMELEN 21) */
Possibly, but the name that can be entered is at most 20 chars long, so
NAMELEN should arguably be defined to 20 and the declaration for name
changed to char name[NAMELEN + 1];. I don't think it adds anything to
readability in this case, though.
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
Miquel, if you're not comfortable integrating all this feedback, mail
me directly (off the list) and I'd be happy to do it for you.
Regards,
--
Tim van Erven
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On 13-Jun-01, 11:24 (CDT), Daniel Ginsburg [EMAIL PROTECTED] wrote:
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
Oops, didn't catch that one.
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
[Steve pulls brown-paper bag over head]
Right. I knew that. That's what I get for taking a quick glance at the
wrong book instead trusting my memory or looking in the standard. I'd
still argue that exit(_macro_) is better style than return from main(),
but I'm hard pressed to find a technical argument.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
Hmmm, right. I should have tried it. This is the kind of thing (rigorous
input validation) one needs to think about when doing security conscious
programming, though.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
Whoa! Amazing :) This is exactly the sort of feedback I expected, thanks a lot guys! I don't have trouble understanding your suggersions, my main delight comes from wondering how on earth can you think of so many tiny details :) And I thought I was paraonid :) Really, thanks a lot, that taught me quite a lot, may be my programming skills improve step by step :) Miquel Martín On Wed, Jun 13, 2001 at 11:29:03PM +0400, Daniel Ginsburg wrote: On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
I think I may ask about this on comp.std.c.
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Since I'm already cluttering up -security with a reply, I'll point out
that adding the braces wasn't strictly appearance. After a few times of
rounds adding a second line to an un-braced if clause, you'll appreciate
the habit of *always* putting in the braces.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 04:10:27PM -0500, Steve Greenland [EMAIL PROTECTED] wrote:
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
I think I may ask about this on comp.std.c.
11.12a:What's the correct declaration of main()? A:Either int main(),
int main(void), or int main(int argc,
char *argv[]) (with alternate spellings of argc and *argv[]
obviously allowed). See also questions 11.12b to 11.15 below.
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Since I'm already cluttering up -security with a reply, I'll point out
that adding the braces wasn't strictly appearance. After a few times of
rounds adding a second line to an un-braced if clause, you'll appreciate
the habit of *always* putting in the braces.
Accept Linus' wisdom about indentation in the CodingStyle file that
comes with your kernel and I can't imagine you'll ever be bothered by
this again.
On the cluttering: I will try to make this my last reply in this
thread.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
I don't see how that could be done if this is used as a login
replacement. Still, it would be caught by fgets, so it's a non-issue.
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Great idea IMHO.
--
Tim van Erven
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Backing up encrypted filesystem
Hi, I have been using reiserfs on top of an encrypted filesystem (serpent) for a couple of months with no problems until last night when the reiserfs crashed. This brings me to my question. Is it possible to burn this filesystem onto a CDR. I have tried unsuccessfully both by using the encrypted file as the image file and also just burning the file onto a iso9660 filesystem. Oh and if anyone knows how to recover a reiserfs with the following error I would be really grateful. -debugreiserfs, 2001- reiserfsprogs 3.x.0j reiserfs_open: first bitmap looks corrupted Super block of format 3.6 found on the 0x3 in block 16 Block count 163840 Blocksize 4096 Free blocks 149868 Busy blocks (skipped 16, bitmaps - 5, journal blocks - 8193 1 super blocks, 5757 data blocks Root block 8214 Journal block (first) 18 Journal dev 0 Journal orig size 8192 Filesystem state VALID Tree height 3 Hash function used to sort names: r5 Objectid map size 18, max 972 Version 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Warning message about /boot/System.map-2.2.19
Hi,
I've also encountered this problem when running a ps after recompiling a
brand new kernel. Apparently, ps (and probably other applications) try
to fetch the System.map in / so if you just symlink it to the new
System.map file it should solve the issue.
Regards,
Chris
Alexander Konovalenko wrote:
I get the following message
{tcp_slt_array} {tcp_slt_array_R__ver_tcp_slt_array}
Warning: /boot/System.map-2.2.19 does not match kernel data.
sometimes (when running ps, for example) on an upgraded Debian potato box
with Linux 2.2.19. I failed to determine the origins of this message.
Can this message signify any security problems?
What program generates it (is it the kernel itself?), why, and what
should I do in order to set up the things correctly?
Additional information: How the the current kernel was installed.
The kernel that was initially installed was 2.2.14. Then 2.2.19 source
was downloaded as a Debian package, unpacked, configured, compiled into a
package with `make-kpkg kernel_image', and then installed with `dpkg -i'.
The /boot directory was cleaned up before the installation, any
necessary Lilo adjustments were made, and Linux 2.2.19 successfully
booted.
Feel free not to send your reply to debian-security if my problem is not
related to security in any way.
Please cc your reply to me.
Please point an appropriate place (a mailing list, a newsgroup) to ask
more about my problem if it cannot be related to security.
Regards,
Alexander Konovalenko
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Christopher `Physicman' Bodenstein mailto:[EMAIL PROTECTED]
BxLUG - BruXelles Linux User Group http://www.bxlug.org/
* Fortune Cookie *
It is common sense to take a method and try it. If it fails,
admit it frankly and try another. But above all, try something.
-- Franklin D. Roosevelt
Kernel 2.4 SOS
Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. I have pointed apt to sid but it wants to pull packages down from woody. Now what i need to know, is woody stable enough for a proxy/firewall machine ? Thanks Craig
Re: Kernel 2.4 SOS
On Wed, 13 Jun 2001, Craig wrote: I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. You don't need to install a full woody system to run a 2.4.x kernel. I administer a large number of potato boxen and just picked the necessary source packages from unstable and recompiled them, with very minor changes to satisfy some different dependencies due to files that belong to different packages between unstable and potato. There are a few sites that make available the needed precompiled packages for potato, if you don't want to do it yourself. Look at http://www.fs.tum.de/~bunk/kernel-24.html and people.debian.org/~bunk/debian. I migh also let you have the debs I recompiled, but I would not trust them if I were in your shoes... :) Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED], [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel.: +39 070 71180 216 Fax : +39 070 71180 222 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 10:48:22AM +0200, Craig wrote: Now what i need to know, is woody stable enough for a proxy/firewall machine I do not know the answer to this as I haven't really used woody yet. But, the stuff you need to make it work smoothly on a potato box can be found starting from here: http://www.debian.org/News/2001/20010415 Fwiw, I had no problems at all using a 2.4 kernel on a regular potato box without the updates mentioned at that link, the only exception was that the old version of modprobe couldn't load any 2.4 modules. So you could: a) update to the modutils package included in the updates above; b) build all your drivers statically into the kernel, thereby not needing modutils; c) write some 'insmod' lines into your scripts to load modules, the old insmod still works fine (and is what I did). HTH.
RE: Kernel 2.4 SOS
Title: RE: Kernel 2.4 SOS Now what i need to know, is woody stable enough for a proxy/firewall machine Just take the packages you need to run 2.4-kernel from woody and continue use potato. That's what i do, works perfect. And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/
Re: Kernel 2.4 SOS
Hi Craig, Now what i need to know, is woody stable enough for a proxy/firewall machine ...no prob at all, woody is nearly stable and i use it since half a year without any probs as a firewall/squid-proxy and as a productive system (intranet-server) for 20 users. for sure these are two different maschines :-) regards joris -- SBF Gruppe - http://www.sbf.de Steinhof 51 - D-40699 Erkrath Tel: +49 211 20 99 51 0 Fax: +49 211 20 99 51 88
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 11:01:10AM +0200, Johan Segernäs wrote: And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. woody also does not get security updates, in fact it can take a very long time for security related updates to get into woody since its almost entirely managed by a script. unstable simply gets new versions of a package installed immediatly so any security fixes are in unstable as soon as they are packaged. that does NOT guarentee they will make it into woody any time soon though. the `testing' distribution (now woody) is the least secure branch you can run. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpOKvuXhy9O4.pgp Description: PGP signature
RE: Kernel 2.4 SOS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! as Giacomo already mailed, you have the possibility to use Adrian's packages from people.debian.org/~bunk/debian. But I had several problems with them using isdn and proxy, etc. I have woody installed on my router/firewall/proxy/fax-server. It's working pretty fine. I have uptimes of over 50 days, only interruped by installing new kernels. I would say woody is quite stable enough for a router, if you can handle some basic problems, which still occour in woody time by time. Michael I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. I have the source downloaded and am busy going though the documentation but some of the packages that the documentation makes reference to is to low a version. I have pointed apt to sid but it wants to pull packages down from woody. Now what i need to know, is woody stable enough for a proxy/firewall machine ? Thanks Craig -BEGIN PGP SIGNATURE- Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com iQA/AwUBOycwmgUqVktPGYHYEQKmxwCg0VqT8BGX249XMCALjerSycqQ7lkAnR3A N7YCfrw0hnyKEsnDSkFmeaED =JRio -END PGP SIGNATURE-
Re: Creating a logfile for Netfilter
On Mon, Jun 11, 2001 at 07:11:00PM +0100, Tim Haynes wrote: Stefan Srdic [EMAIL PROTECTED] writes: Anyway, as you can guess I am using netfilter for firewalling. How can I pipe all logs from Netfilter into a single logfile? Lets say I wanted all log messages from netfilter to be loged into /var/log/netfilter. How could I accomplish that? FWIW, my approach: assert a log-prefix in your logging iptables rules, and install syslog-ng with a regexp match to pick up your prefix (make it distinctive, eg 'Catch-all: .*IN=.*OUT=' would probably be precise enough). Here is an alternative approach which I took. I think it is a little easier. If you create a user defined chain something like the following: iptables -N log_droped iptables -A log_droped -j LOG --log-level 1 --log-prefix droped_:: iptables -A log_droped -j DROP And make all your firewall rules that need to be dropped -j (jump) to this chain then they will be logged at log-level 1 (Alert). Then, if you edit /etc/syslog.conf and append the following line: kern.=alert -/var/log/firewall.log (Nb. line up with tabs) Then syslog will log all logs at level alert to the separate file. Not much else gets logged at level alert so it should be OK and not upset other logging. Thus, the firewall will log to /var/log/firewall.log - just create this file with touch. Hth. Mark.
Re: Kernel 2.4 SOS
On Wed, Jun 13, 2001 at 12:21:44PM +0200, Joris Mocka wrote: Ethan Benson wrote: On Wed, Jun 13, 2001 at 11:01:10AM +0200, Johan Segernäs wrote: And no, i wouldn't use woody on a firewall, it's to many packet-updates all the time, takes to much time to keep track of everything imho. woody also does not get security updates, in fact it can take a very long time for security related updates to get into woody since its almost entirely managed by a script. unstable simply gets new versions of a package installed immediatly so any security fixes are in unstable as soon as they are packaged. that does NOT guarentee they will make it into woody any time soon though. the `testing' distribution (now woody) is the least secure branch you can run. ...this is a thing where i can't agree, in the last 6 month, all security-fixes were as soon implemented as in potato (i have both, so i'd compared). e.g. bind probs, man-db probs for mention a few. but i have also the security-link in my sources.list even under woody, maybe this is the reason why it works. What is the security link? Mark.
Re: Kernel 2.4 SOS
Ethan Benson wrote: security.debian.org is only for stable, it won't work on woody or unstable since they almost invariably have newer versions then what goes in security.debian.org. the fact you have so far seen good results with security is mostly chance. if a security fix has some dependency issue, or bug reports, it won't go in unless forced. ...ok you're right, only packages which have not changed in woody would be applied then there is nothing guarenteeing fixes will go in and there is a good chance they won't. there isn't a security team for anything but stable. beware. of course the same goes for unstable, if you use any branch other then stable you are responsible for checking that security fixes are getting made and installed, there won't be an advisory. ...also you're right :-) so or so i always have to be aware about my systems and i think i had luck in the last half year to get the right updates at the right time. regards joris -- SBF Gruppe - http://www.sbf.de Steinhof 51 - D-40699 Erkrath Tel: +49 211 20 99 51 0 Fax: +49 211 20 99 51 88
Re: Kernel 2.4 SOS
Craig wrote: Goodday ladies and fellas I have potato installed on a box that will be a proxy and firewall. I needed to have the facility of port forwarding so i was told to install kernel 2.4. Does kernel 2.4 have some special feature of port forwarding that the 2.2.x kernels don't have? I don't see why mess with 2.4 at all when kernel 2.2.17 (potato rev0) or higher will handle port forwarding just fine. And by just using potato, you can keep up with the security updates easier.
Re: Security in a shell that starts ssh
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
charname[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
{
char name[21]; /* Should be macro (#define NAMELEN 21) */
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
--
dg
Re: Security in a shell that starts ssh
Thanks for the feedback, I'll respond to both your replies at once.
On Wed, Jun 13, 2001 at 08:24:32PM +0400, Daniel Ginsburg [EMAIL PROTECTED]
wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
Tim, good fixups, a few C coding/style nitpicks:
On 12-Jun-01, 17:57 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
#include stdio.h
#include unistd.h /* For execlp */
#include stdlib.h /* For exit */
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
{
charname[21]; /* Should be macro (#define NAMELEN 21) */
Possibly, but the name that can be entered is at most 20 chars long, so
NAMELEN should arguably be defined to 20 and the declaration for name
changed to char name[NAMELEN + 1];. I don't think it adds anything to
readability in this case, though.
printf(Login as: );
fflush(stdout);
if(fgets(name, 21, stdin)) {
/* if(name[strlen(name) - 1] != '\n') */
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
fprintf(stderr, Username to long.\n);
/* else { */
} else {
name[strlen(name) - 1] = '\0';
execlp(/usr/bin/ssh, ssh, -l, name, foo.foo.es, (char *)0);
}
}
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered
functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
}
You also should should make sure name doesn't contain any spaces: as
written I can pass additional options to ssh. Also, for this kind of
application you really ought to be checking the error conditions for
*every* library call.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
Miquel, if you're not comfortable integrating all this feedback, mail
me directly (off the list) and I'd be happy to do it for you.
Regards,
--
Tim van Erven
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On 13-Jun-01, 11:24 (CDT), Daniel Ginsburg [EMAIL PROTECTED] wrote:
if(name[strlen(name) - 1] != '\n') {
Possible access to unallocated memory if \0\n supplied as input.
Oops, didn't catch that one.
/* return 0; */
exit(EXIT_SUCCESS); /* return doesn't call atexit() registered
functions,
which doesn't apply in this case, but it's a good
habit to get into */
Wrong comment. Returning from main _does_ call atexit() registered
functions.
[Steve pulls brown-paper bag over head]
Right. I knew that. That's what I get for taking a quick glance at the
wrong book instead trusting my memory or looking in the standard. I'd
still argue that exit(_macro_) is better style than return from main(),
but I'm hard pressed to find a technical argument.
Spaces and other shell metacharecters are irrelevant in this case, since
executed command won't undergo shell interpretation.
Hmmm, right. I should have tried it. This is the kind of thing (rigorous
input validation) one needs to think about when doing security conscious
programming, though.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg
Re: Security in a shell that starts ssh
Whoa! Amazing :) This is exactly the sort of feedback I expected, thanks a lot guys! I don't have trouble understanding your suggersions, my main delight comes from wondering how on earth can you think of so many tiny details :) And I thought I was paraonid :) Really, thanks a lot, that taught me quite a lot, may be my programming skills improve step by step :) Miquel Martín On Wed, Jun 13, 2001 at 11:29:03PM +0400, Daniel Ginsburg wrote: On Wed, Jun 13, 2001 at 02:02:10PM -0500, Steve Greenland wrote: [snip] I'd still argue that exit(_macro_) is better style than return from main(), but I'm hard pressed to find a technical argument. There's subtle difference between returning from main and calling exit. Excelent explanation is in C-FAQ 11.16 http://www.eskimo.com/~scs/C-faq/q11.16.html. -- dg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
I think I may ask about this on comp.std.c.
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Since I'm already cluttering up -security with a reply, I'll point out
that adding the braces wasn't strictly appearance. After a few times of
rounds adding a second line to an un-braced if clause, you'll appreciate
the habit of *always* putting in the braces.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Steve
--
Steve Greenland [EMAIL PROTECTED]
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 04:10:27PM -0500, Steve Greenland [EMAIL PROTECTED]
wrote:
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
I think I may ask about this on comp.std.c.
11.12a:What's the correct declaration of main()? A:Either int main(),
int main(void), or int main(int argc,
char *argv[]) (with alternate spellings of argc and *argv[]
obviously allowed). See also questions 11.12b to 11.15 below.
if(name[strlen(name) - 1] != '\n') {
Yes, this does look slightly better.
Since I'm already cluttering up -security with a reply, I'll point out
that adding the braces wasn't strictly appearance. After a few times of
rounds adding a second line to an un-braced if clause, you'll appreciate
the habit of *always* putting in the braces.
Accept Linus' wisdom about indentation in the CodingStyle file that
comes with your kernel and I can't imagine you'll ever be bothered by
this again.
On the cluttering: I will try to make this my last reply in this
thread.
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
I don't see how that could be done if this is used as a login
replacement. Still, it would be caught by fgets, so it's a non-issue.
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Great idea IMHO.
--
Tim van Erven
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 04:10:27PM -0500, Steve Greenland wrote:
On 13-Jun-01, 13:47 (CDT), Tim van Erven [EMAIL PROTECTED] wrote:
On Wed, Jun 13, 2001 at 10:57:08AM -0500, Steve Greenland wrote:
int main()
int main(void) /* () != (void) in C */
The comp.lang.c faq (http://www.faqs.org/faqs/C-faq/faq/) says it's ok.
Where does it say this? The only thing I can see is under 11.12, where
it says main must be declared as returning an int, and as taking either
zero or two arguments, of the appropriate types. That means either 'int
main(void)' or 'int main(int argc, char *argv[])' (or 'char **argv'
or some other compatible variations). 'int main()' has unspecified
arguments, not zero.
11.12a: What's the correct declaration of main()?
A: Either int main(), int main(void), or int main(int argc,
char *argv[]) (with alternate spellings of argc and *argv[]
obviously allowed). See also questions 11.12b to 11.15 below.
References: ISO Sec. 5.1.2.2.1, Sec. G.5.1; HS Sec. 20.1 p.
416; CTP Sec. 3.10 pp. 50-51.
Or does it? Since it's a definition, not a declaration, it *is* a
function with no arguments. OTOH, the standard specifically says main
should be either 'int main(void)' or 'int main(int argc, char **argv)'.
Exactly because it's definition int main() is correct too, but spelling it
as int main(void) is better style IMHO.
I think I may ask about this on comp.std.c.
Oh no, not again! :)
[snip]
Possible access to unallocated memory if \0\n supplied as input.
Only if strlen(name) = 0 and besides from being hard to achieve when
entering data on stdin, fgets will return 0 if that happens.
But not if you feed it a file.
Or socket, or whatever.
BTW, fgets will have non-NULL return value if that happens. Unfortunately
fgets won't report number of characters read. So it's better resort to
reading one character at time with fgetc if it's important to know how much
data we got.
No comments about my spelling mistake ('to long')? Personally I
considered that the worst offence. Btw, I should start posting all my
code to this list. That would *really* fix-up my coding habbits. :)
[EMAIL PROTECTED] anyone? The place I used to work did
code reviews for a short while: humbling and immensely valueable. I
don't know why we got out of that habit; probably someone decided it
took too long, as if fixing bugs in released products was cheap.
Ah, now try to convince people to submit their code for review. :)
Unfortunately many people take comments on their coding style as personal
offense :(
--
dg
Re: Security in a shell that starts ssh
On Wed, Jun 13, 2001 at 11:34:28PM +0200, Tim van Erven wrote: [snip] Possible access to unallocated memory if \0\n supplied as input. Only if strlen(name) = 0 and besides from being hard to achieve when entering data on stdin, fgets will return 0 if that happens. But not if you feed it a file. I don't see how that could be done if this is used as a login replacement. Still, it would be caught by fgets, so it's a non-issue. [EMAIL PROTECTED] It _won't_ be caught by fgets. See my other post. Please refer to manpages and the Standard to see what does fgets return and under what circumstances. -- dg
