Re: [patch] lockf(3) user-exploitable kernel panic

• Previous message: Jari Kirma: "Digital-tv card drivers and API discussion"
• In reply to: Devon H. O'Dell: "Re: [patch] lockf(3) user-exploitable kernel panic"
• Next in thread: dodell_at_sitetronics.com: "Re: [patch] lockf(3) user-exploitable kernel panic"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 15 Apr 2004 11:06:22 +0000
To: "Devon H. O'Dell" <dodell@sitetronics.com>

On Wed, Apr 14, 2004 at 01:51:03PM +0200, Devon H. O'Dell wrote:
> Jilles Tjoelker wrote:
> >e) add a line 'struct proc;' to sys/ucred.h
>
> Thanks for this suggestion; I wasn't aware that this was reasonably
> possible from an architectural standpoint.

Most of the sys/* files are really owned by the implementation, and it
is usually OK to introduce forward declarations into them. We try to
avoid namespace poisoning (introducing unknown variables) for the
official files, but that also happens sometimes.

Also, many of the files (including sys/ucred.h) has an #ifdef _KERNEL
section. This section is totally owned by the implementation, and it is
(almost) always OK to add forward declarations.

The list of official sys/ includes can be fetched at
http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/

> >>3) Does this work justify my going through the modified files and doing
> >>style(9) changes on them? I'm willing to do this; mux@ has encouraged
> >>it; style(9) suggests that I do it if my code comprises 50% or more of
> >>the new files (which it doesn't). Again, if this is useful, I'll
> >>certainly do this.
> >
> >Some of the files have a mixture of K&R-style and ANSI function
> >definitions.
>
> I'll look into implementing style(9) changes then. I know my patch fails
> a style(9) check in some contexts, so I'll go a general cleanup as well.

Please do that separately from the main patch. We try quite hard to not
mix stylistic and functional changes in a single patch, to make it easy
to use the version history (and easy for people to review the patches).

> sh has been fixed. I was under the impression that csh used libutil for
> this (libutil has been fixed). I'll take a deeper look into shells in
> base and in ports and figure out what changes I need to make there.
> While I'm at it, I don't think it'd be a bad idea to go ahead and build
> in the RLIMIT_SBSIZE to bash and bash2.

If it is easy, it might be worthwhile to patch the shells to use
libutil and submit those patches back to the maintainers.

> >Limiting the number of locked regions is not uncommon, e.g. Solaris does
> >it (the manpage seems to indicate a per-system limitation only, though).
> >
> >Interesting part from Linux getrlimit(2) manpage:
> > RLIMIT_LOCKS
> > A limit on the combined number of flock() locks and
> > fcntl()
> > leases that this process may establish (Linux 2.4 and later).
> >
> >Per-user instead of per-process limits are harder to implement but
> >more effective.
>
> Ok. I was not aware that Linux had this fix / feature already. I'll take
> a look into the CVS repos of the other BSDs and see if it's something I
> can suggest a patch for in those worlds.

It'd be nice to be compatible with Linux here, as it means just a define
is needed for making apps work with it on FreeBSD (it may even
automatically happen due to configure scripts.)

Eivind.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

• Previous message: Jari Kirma: "Digital-tv card drivers and API discussion"
• In reply to: Devon H. O'Dell: "Re: [patch] lockf(3) user-exploitable kernel panic"
• Next in thread: dodell_at_sitetronics.com: "Re: [patch] lockf(3) user-exploitable kernel panic"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]