• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Ping question

Status
Not open for further replies.

kepler

Junior Member
This is totally a curiosity post:

So a colleague and I were helping someone set up their path (so he could ping without typing the full path) on a Solaris machine, which begged us to question why ping was suid.

We wanted to remove the suid bit and truss, but it was a production level server, so we just were strace'ing on our linux workstations.

While strace would stop because we couldn't strace processes ran as root, we did notice this line:

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(49813), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(3)

We couldn't figure out why it was opening SOCK_DGRAM for a ping.

Checking up on ping:

http://en.wikipedia.org/wiki/Ping_(networking_utility)

The payload looks totally TCP/IP, so we have no idea why UDP is involved.

On a side note, the above strace was pinging without being root, here is one with root -- still does the UDP thing:

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(48852), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
close(4)

When tcpdump'ed, I see no UDP traffic anywhere -- and tested pinging other hosts/tcpdump'ing on them as well, not just localhost.
 
Status
Not open for further replies.
Back
Top