This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #15763][BZ #14752] Restrict shm_open and shm_unlink to SHMDIR.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 30 Oct 2013 16:36:37 +0100
- Subject: Re: [PATCH][BZ #15763][BZ #14752] Restrict shm_open and shm_unlink to SHMDIR.
- Authentication-results: sourceware.org; auth=none
- References: <20131015073738 dot GA32465 at domone dot podge> <5264FB77 dot 7090400 at redhat dot com> <20131023124140 dot GA5434 at domone dot podge> <526812E1 dot 5010700 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1310231918380 dot 28882 at digraph dot polyomino dot org dot uk>
On Wed, Oct 23, 2013 at 07:26:25PM +0000, Joseph S. Myers wrote:
> On Wed, 23 Oct 2013, Florian Weimer wrote:
> > Sorry, I missed the NAME_MAX reference. I don't think it's guarantueed to be
> > available. I see that it's desirable to have some upper bound to avoid alloca
> > issues. Not sure if it's okay to put in some arbitrary constant (1024 would
> > be fine in my book).
> I believe such limits are fine in files in sysdeps/unix/sysv/linux, as
> long as they use the appropriate macro and it describes an actual limit in
> the kernel (NAME_MAX comes from linux/limits.h and I think does describe
> an actual kernel limit), just not in generic files that may be used on
> other systems without such limits.
> (Quite a lot of the fallback code for !__ASSUME_ATFCTS really should be
> using a PATH_MAX check so an appropriate error, rather than oversized
> alloca, occurs for very long arguments.)
As this is clarified is rest ok?