Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » php5 reads /etc/group on start »

php5 reads /etc/group on start

php.internals

kjc

20 years ago
What is it that php5.1.2 reads /etc/group on startup to setgroup? My Solaris 10 boxes use LDAP as a NIS replacement so that we don't have to manage individual group files on all the servers. When I start Apache without php I see this the dtrace dtruss script: log.dtruss-httpdcmd-nophp: 26471/1: read(0xE, "0\202\001\b\002\001\002d\202\001\001\004\034cn=cau,ou=group,ou=dev ... <snip> log.dtruss-httpdcmd-nophp:26483/1: setgroups(0xA, 0x1001F20A0, 0x400) = 0 0 times ten, for the ten (A) groups that the webuser is a member of, thus the setgroups(0xA,. BUT... When I LoadModule libphp5 I get this instead: log.dtruss-httpdcmd: 25142/1: open("/etc/group\0", 0x2000, 0x1B6) = 15 0 log.dtruss-httpdcmd: 25142/1: setgroups(0x2, 0x1002CCFB0, 0x400) = 0 0 Which is a grand total of 3 (2), one from /etc/group and the other is what is actually associated with the LDAP user webuser but listed twice. So-- why does PHP manually go and read /etc/group-- and why? And how can I disable or fix that? HELP!! TIA. -Kevin

Rasmus Lerdorf

20 years ago
kjc wrote:
> What is it that php5.1.2 reads /etc/group on startup to setgroup? > > My Solaris 10 boxes use LDAP as a NIS replacement so that we don't have to > manage individual group files on all the servers. > > When I start Apache without php I see this the dtrace dtruss script: > log.dtruss-httpdcmd-nophp: 26471/1: read(0xE, > "0\202\001\b\002\001\002d\202\001\001\004\034cn=cau,ou=group,ou=dev ... > <snip> > log.dtruss-httpdcmd-nophp:26483/1: setgroups(0xA, 0x1001F20A0, > 0x400) = 0 0 > > times ten, for the ten (A) groups that the webuser is a member of, thus the > setgroups(0xA,. > > > BUT... When I LoadModule libphp5 I get this instead: > > log.dtruss-httpdcmd: 25142/1: open("/etc/group\0", 0x2000, > 0x1B6) = 15 0 > log.dtruss-httpdcmd: 25142/1: setgroups(0x2, 0x1002CCFB0, > 0x400) = 0 0 > > > Which is a grand total of 3 (2), one from /etc/group and the other is what > is actually associated with the LDAP user webuser but listed twice. > > So-- why does PHP manually go and read /etc/group-- and why? And how can I > disable or fix that?
Obviously PHP doesn't read that file directly. Figure out which libc call leads to that call and we might be able to help. -Rasmus

kjc

20 years ago
Thanks for responding... I see the following GID calls from libc, supplying both w/php and w/o php. Hmm. what next? logfile: CALL COUNT log.dappprof-apachectl:libc.so.1 getgid 1 log.dappprof-apachectl:libc.so.1 getpgid 1 log.dappprof-apachectl:libc.so.1 getegid 1 log.dappprof-apachectl:libc.so.1 getpgid 25400 log.dappprof-apachectl:libc.so.1 getgid 27700 log.dappprof-apachectl:libc.so.1 getegid 32100 log.dappprof-apachectl:libc.so.1 getpgid 2400 log.dappprof-apachectl:libc.so.1 getgid 3800 log.dappprof-apachectl:libc.so.1 getegid 6700 log.dappprof-apachectl-nophp:libc.so.1 getegid 1 log.dappprof-apachectl-nophp:libc.so.1 getgid 1 log.dappprof-apachectl-nophp:libc.so.1 getpgid 1 log.dappprof-apachectl-nophp:libc.so.1 getpgid 25600 log.dappprof-apachectl-nophp:libc.so.1 getgid 27000 log.dappprof-apachectl-nophp:libc.so.1 getegid 28200 log.dappprof-apachectl-nophp:libc.so.1 getpgid 2300 log.dappprof-apachectl-nophp:libc.so.1 getgid 3400 log.dappprof-apachectl-nophp:libc.so.1 getegid 4800 On 3/8/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> > > > Obviously PHP doesn't read that file directly. Figure out which libc > call leads to that call and we might be able to help. > > -Rasmus >
-- -Kevin

kjc

20 years ago
i've done some more analysis and I see where it uses /usr/lib/nss_files.so.1 during the start up phase- probably this very getgroups call. I think that would do it. but why? another question: is the ext/posix/posix.c bypassed when configured --disable-posix? your help is very much appreciated. On 3/8/06, kjc <ckevinj@gmail.com> wrote:
> Thanks for responding... > I see the following GID calls from libc, supplying both w/php and w/o php. > Hmm. what next? > > logfile: CALL COUNT > log.dappprof-apachectl:libc.so.1 > getgid 1 > log.dappprof-apachectl:libc.so.1 > getpgid 1 > log.dappprof-apachectl:libc.so.1 > getegid 1 > log.dappprof-apachectl:libc.so.1 > getpgid 25400 > log.dappprof-apachectl:libc.so.1 > getgid 27700 > log.dappprof-apachectl:libc.so.1 > getegid 32100 > log.dappprof-apachectl:libc.so.1 > getpgid 2400 > log.dappprof-apachectl:libc.so.1 > getgid 3800 > log.dappprof-apachectl:libc.so.1 > getegid 6700 > log.dappprof-apachectl-nophp:libc.so.1 > getegid 1 > log.dappprof-apachectl-nophp:libc.so.1 > getgid 1 > log.dappprof-apachectl-nophp:libc.so.1 > getpgid 1 > log.dappprof-apachectl-nophp:libc.so.1 > getpgid 25600 > log.dappprof-apachectl-nophp:libc.so.1 > getgid 27000 > log.dappprof-apachectl-nophp:libc.so.1 > getegid 28200 > log.dappprof-apachectl-nophp:libc.so.1 > getpgid 2300 > log.dappprof-apachectl-nophp:libc.so.1 > getgid 3400 > log.dappprof-apachectl-nophp:libc.so.1 > getegid 4800 > > > > > On 3/8/06, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > > > > > > > > Obviously PHP doesn't read that file directly. Figure out which libc > > call leads to that call and we might be able to help. > > > > -Rasmus > > > > > > -- > -Kevin > >
-- -Kevin