You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@apr.apache.org by bu...@apache.org on 2020/09/17 12:46:27 UTC

[Bug 64746] New: our_ftok() can produce SHM ids with low order bits all zero

https://bz.apache.org/bugzilla/show_bug.cgi?id=64746

            Bug ID: 64746
           Summary: our_ftok() can produce SHM ids with low order bits all
                    zero
           Product: APR
           Version: HEAD
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: APR
          Assignee: bugs@apr.apache.org
          Reporter: covener@gmail.com
  Target Milestone: ---

posix says:

Only the low-order 8-bits of id are significant. The behavior of ftok() is
unspecified if these bits are 0.

#if APR_USE_SHMEM_SHMGET
static key_t our_ftok(const char *filename)
{
    /* to help avoid collisions while still using
     * an easily recreated proj_id */
    apr_ssize_t slen = strlen(filename);
    return ftok(filename,
                (int)apr_hashfunc_default(filename, &slen));
}
#endif


If you get unlucky the default hash function can return values that hit the
unspecified case, on my nightly test system this happens occasionally based on
the parent pid of of httpd, here is an unlucky one: /tmp/httpd_lua_shm.66808

Which hashes to 1477165056
0b1011000000010111100000000000000

Would even a minor change to our_ftok() require a release boundary to be
changeable when APR is not embedded?

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 64746] our_ftok() can produce SHM ids with low order bits all zero

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64746

--- Comment #4 from Joe Orton <jo...@redhat.com> ---
+1 from me

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 64746] our_ftok() can produce SHM ids with low order bits all zero

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64746

--- Comment #2 from Eric Covener <co...@gmail.com> ---
This was changed from a constant to a hash across the filename because the bug
below that points to NOTES in the linux/glibc manual that says separate
filenames with the same low 16bits in the inode can collide too.

https://bz.apache.org/bugzilla/show_bug.cgi?id=53996


Collided with Joe:

Yes, we see it fail w/ EINVAL on z/OS.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 64746] our_ftok() can produce SHM ids with low order bits all zero

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64746

--- Comment #1 from Joe Orton <jo...@redhat.com> ---
We changed from plain ftok() to our_ftok() in 1.5 so should be fine to fudge it
IMO.  Is there any platform where ftok actually misbehaves when passed 0?  IIRC
most implementations simply XOR the inode number with the project ID

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

[Bug 64746] our_ftok() can produce SHM ids with low order bits all zero

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64746

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |PatchAvailable

--- Comment #3 from Eric Covener <co...@gmail.com> ---
fall back to 1 if the ID looks suspicious?

http://people.apache.org/~covener/patches/pr64746.diff

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org