Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #35601 > unrolled thread

inetutils for Slackware

Back to article view | Back to alt.os.linux.slackware

Contents

  inetutils for Slackware jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-05-30 16:35 -0400
    Re: inetutils for Slackware Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2026-05-31 11:24 +0000
      Re: inetutils for Slackware kaukasoina3dore73js4@sci.fi (Petri Kaukasoina) - 2026-05-31 12:27 +0000
        Re: inetutils for Slackware kaukasoina3dore73js4@sci.fi (Petri Kaukasoina) - 2026-05-31 12:55 +0000
      Re: inetutils for Slackware jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-05-31 18:27 -0400
        Re: inetutils for Slackware Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2026-06-01 05:24 +0000
    Re: inetutils for Slackware Marco Moock <mm@dorfdsl.de> - 2026-05-31 19:36 +0200
      Re: inetutils for Slackware Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> - 2026-06-01 05:28 +0000
    Re: inetutils for Slackware Sylvain Robitaille <syl@therockgarden.ca> - 2026-06-01 04:41 +0000

#35601 — inetutils for Slackware

This is another one of those things that I've been running for years and
wish was a part of base Slackware. Slackware gets alot of its support
for older TCPIP tools from multiple packages: the net-kit stuff,
net-tools, iputils and others. Many of these are unmaintained. Then
there's inetd and sysklog. If you use inetutils, you don't need almost
all of that. It's just one package. This is a Slack build (but not a
SlackBuild) for Slackware Current (but likely works on 15).

Pros:
- inetutils is a mature GNU project that changes little
- inetutils is being actively maintained (there was a release recently)
- inetutils can install with Linux caps, thus increasing security
because setruid binaries are no longer needed. Consider the recent
dirty.frag vulns for a reason why to avoid setruid
- inetutils has a larger collection of utilities
- inetutuls has an texinfo file detailing all the tools in one place

Cons:
- some conflicts with net-kit, net-tools (uninstall or let them be
clobbered)
- two 'pings', you can leave both /bin/ping and /usr/bin/ping or delete
the old one at /bin/ping if you are confident
- ifconfig does not support ipv6 (I left it off the build list for this
reason) so the net-tools one is still needed if you care about ifconfig

inetutils works well with xinetd, rsyslog, and iproute2 (which is how I
have it setup) though inetutil's inetd and syslogd are fully usable.

Note no setruid:
-rwxr-xr-x   1 root   root        60632 May 30 14:44  traceroute*
-rwxr-xr-x   1 root   root       145368 May 30 14:44  telnet*
-rwxr-xr-x   1 root   root        68560 May 30 14:44  talk*
-rwxr-xr-x   1 root   root        56400 May 30 14:44  rsh*
-rwxr-xr-x   1 root   root        60752 May 30 14:44  rlogin*
-rwxr-xr-x   1 root   root        56464 May 30 14:44  rexec*
-rwxr-xr-x   1 root   root        64696 May 30 14:44  rcp*
-rwxr-xr-x   1 root   root        65528 May 30 14:44  ping6*
-rwxr-xr-x   1 root   root        74648 May 30 14:44  ping*
-rwxr-xr-x   1 root   root       136920 May 30 14:44  ftp*
-rwxr-xr-x   1 root   root        55896 May 30 14:44  dnsdomainname*

getcap /usr/bin/rlogin
/usr/bin/rlogin cap_net_bind_service=eip
getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=eip

Old way:
ls -l /bin/ping
-rws--x--x 1 root root 164216 Jun  5  2025 /bin/ping*

Full functionality without setruid:
/usr/bin/ping -c 2 kirin.lan
PING kirin (192.168.20.4): 56 data bytes
64 bytes from 192.168.20.4: icmp_seq=0 ttl=255 time=5.397 ms
64 bytes from 192.168.20.4: icmp_seq=1 ttl=255 time=7.032 ms
--- kirin ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.397/6.215/7.032/0.817 ms

rlogin kirin
$ show system /noproc
OpenVMS V7.3  on node KIRIN  30-MAY-2026 16:03:45.64  Uptime  9 20:32:48
$ logout
rlogin: Connection to kirin closed normally.03:54.69

traceroute fatalis.lan
traceroute to fatalis (192.168.20.59), 64 hops max
  1   192.168.20.59  1.440ms  1.348ms  1.362ms
  

I know approaching zero people will actually use this, and Slackware
would never consider it, but once I have a project in mind I have to
complete it so here we are.

ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/inetutils.tar.gz
PGP in inetutils.tar.gz.asc

Note inetutils wants gnulib from GIT, unlike days past when this was
included in the source archive. The script handles all of this and is
explained at the top of inetutils.SlackBuild . A blacklist snippet is
also suggested for you if you use slackpkg (I do). The pulling down of
the GIT repo (for gnulib) only happens once, during bootstrap; the
script checks for the existance of a source directory and doesn't do it
again if it doesn't have to. 

A detailed buildlog is kept as well, so if something goes wrong you can
see what it was.

cat BuildLog.txt 
++++ Sat May 30 14:43:19 EDT 2026 building inetutils
        VERSION -> v2.8
        DIRVER -> v2.8
        TARARCH -> inetutils-v2.8-src.tar.gz
        BUILD -> 1_jayjwa
        NUMJOBS ->  -j9 
        ARCH -> x86_64
        CC -> ccache gcc
        CFLAGS -> -pipe -O2
        TMP -> /tmp
        PKG -> /tmp/package-inetutils
Opening source tar archive
Source code tree available
Configured 
Running make 
Packaging the files and binaries
Loaded docs
Populated /install/ subdir
Moving binaries into place and cleaning up unused dirs
Man pages zipped
Binaries stripped for size
++++ inetutils build complete at Sat May 30 14:44:33 EDT 2026

-- 
PGP Key ID: 781C A3E2 C6ED 70A6 B356  7AF5 B510 542E D460 5CAE
       "The Internet should always be the Wild West!"

[toc] | [next] | [standalone]

#35603

On Sat, 30 May 2026 16:35:39 -0400, jayjwa wrote:
> Slackware gets alot of its support for older TCPIP tools from multiple
> packages: the net-kit stuff, net-tools, iputils and others. Many of
> these are unmaintained.

The fact that there is a maintained alternative to the currently choosen 
unmaintained alternative could be a good reason to switch. However, those 
unmaintained tools also come with a big fat warning, from 
/usr/doc/netkit-rsh-0.17/README (dated year 2000)

"Note: None of these programs provide encryption or strong
authentication of network connections. As such, their use is
discouraged. The "ssh" protocol and package is a cryptographically
secure replacement."

I do realize that there are situations where you don't want network 
traffic to be encrypted, like when streaming live video, but even with 
ssh it is still possible to choose not to encrypt X. In most cases 
though, ssh with its X tunneling is much more convenient for the user 
than manually messing with DISPLA environment variable and xhost.

> Cons:
> - some conflicts with net-kit, net-tools (uninstall or let them be
> clobbered)

Which did you choose? Uninstallation of the conflicting packages?

> getcap /usr/bin/ping
> /usr/bin/ping cap_net_raw=eip
> 
> Old way:
> ls -l /bin/ping -rws--x--x 1 root root 164216 Jun  5  2025 /bin/ping*

It would be fully possible to do the same with the stock Slackware 
binaries:

Quick test as root:
-8<------------------------------
bash-4.3# cp /bin/ping /tmp
bash-4.3# chmod u-s /tmp/ping 
bash-4.3# setcap cap_net_raw=eip /tmp/ping 
-8<------------------------------

Then, as a normal user:
-8<------------------------------
nazgul:~> /tmp/ping balrog
PING balrog (192.168.43.3) 56(84) bytes of data.
64 bytes from balrog (192.168.43.3): icmp_seq=1 ttl=64 time=0.134 ms
64 bytes from balrog (192.168.43.3): icmp_seq=2 ttl=64 time=0.192 ms
^C
--- balrog ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.134/0.163/0.192/0.029 ms
nazgul:~> 
-8<------------------------------

However, it is nice with an upstream provider which chooses the setcap 
solution by default.

> I know approaching zero people will actually use this, and Slackware
> would never consider it, but once I have a project in mind I have to
> complete it so here we are.
> 
> ftp://atr2.ath.cx/pub/operating-systems/linux/slackbuilds/
inetutils.tar.gz
> PGP in inetutils.tar.gz.asc

Thanks for sharing! Maybe someone will find it useful. Maybe, even if not 
adopted, it will inspire Slackware to replace some setuid binaries with 
setcap binaries. However, the setcap properties will get lost in gnu tar 
archives:

-8<------------------------------
bash-4.3# getcap ping
ping = cap_net_raw+eip
bash-4.3# mkdir 2
bash-4.3# tar -cf - ping | (cd 2; tar -xvf -)
ping
bash-4.3# getcap 2/ping 
bash-4.3# 
-8<------------------------------

Is that the reason you haven't created any SlackBuild to create a 
Slackware package? Such a slackware package would need a doinst.sh to set 
those properties on the files.

regards Henrik

[toc] | [prev] | [next] | [standalone]

#35604

Henrik Carlqvist  <Henrik.Carlqvist@deadspam.com> wrote:
>However, the setcap properties will get lost in gnu tar archives

The same with rsync or cp. Meaning trouble with backups.

[toc] | [prev] | [next] | [standalone]

#35605

Petri Kaukasoina <kaukasoina3dore73js4@sci.fi> wrote:
>Henrik Carlqvist  <Henrik.Carlqvist@deadspam.com> wrote:
>>However, the setcap properties will get lost in gnu tar archives
>
>The same with rsync or cp. Meaning trouble with backups.

A correction: 'cp -a' copies the capabilities attached to executable files.

[toc] | [prev] | [next] | [standalone]

#35607

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> writes:

> "Note: None of these programs provide encryption or strong
> authentication of network connections. As such, their use is
> discouraged. The "ssh" protocol and package is a cryptographically
> secure replacement."
If you can get TOPS-10, TOPS-20, or ITS speaking SSH I'd love to see it
:-))) . Mostly I use the clients, and ftp is being handled by proftpd
at the moment.

> Which did you choose? Uninstallation of the conflicting packages?
I just blacklisted the official ones and let inetutils clobber what was
already there.

> It would be fully possible to do the same with the stock Slackware 
> binaries:
Of course. But when I got shot down suggesting mtr-packet be set
cap_net_raw I realized I didn't want to fight this battle - at least on
LQ.

> However, the setcap properties will get lost in gnu tar 
> archives:
You put that code in doinst.sh. That's what my build does. The files
install correctly. doinst.sh runs after binaries are installed
in-system. All this is in the .tar.gz linked yesterday.

## doinst.sh for inetutils
##
## Give Linux capabilities(7) permissions to those few
## binaries that need it rather than using full
## setruid. "setcap" is in /sbin which should always
## be PATH'd

# Function to give cap_net_raw for all files given
lx_cap_setraw() {
    local infile
    for infile in $@; do
	setcap cap_net_raw=eip usr/bin/${infile}
    done
}

# Function to give cap_net_bind_service for all files given
lx_cap_setbind() {
    local infile
    for infile in $@; do
	setcap cap_net_bind_service=eip usr/bin/${infile}
    done
}

# Give binaries that need raw sockets special powers
lx_cap_setraw ping ping6 traceroute

# Give binaries that need a privileged port special powers
lx_cap_setbind rcp rlogin rsh rexec

## EOF


> Is that the reason you haven't created any SlackBuild to create a 
> Slackware package?
Umm...that's exactly what I did. That is the point of my posting
this. If you mean the compiled binaries, that package is on the same ftp
server, but in the pub/operating-systems/linux/slackware-package/
area. I assume most people want to build the binaries themselves. 

-- 
PGP Key ID: 781C A3E2 C6ED 70A6 B356  7AF5 B510 542E D460 5CAE
       "The Internet should always be the Wild West!"

[toc] | [prev] | [next] | [standalone]

#35611

On Sun, 31 May 2026 18:27:00 -0400, jayjwa wrote:
>> It would be fully possible to do the same with the stock Slackware
>> binaries:
> Of course. But when I got shot down suggesting mtr-packet be set
> cap_net_raw I realized I didn't want to fight this battle - at least on
> LQ.

Sorry, it was probably my post on LQ that you are referring to. I agree 
that replacing setuid with a setcap can make things more secure but 
applying a new setcap to a file lacking setuid might give normal users 
the power to mess things up.
 
> Umm...that's exactly what I did.

Sorry for the confusion, I did not study the files you linked to and your 
text "This is a Slack build (but not a SlackBuild)" made me think that 
you hadn't written any SlackBuild script to create a  package but only a 
script that built and installed the software.

regards Henrik

[toc] | [prev] | [next] | [standalone]

#35606

Am 30.05.26 um 22:35 schrieb jayjwa:
> This is another one of those things that I've been running for years and
> wish was a part of base Slackware. Slackware gets alot of its support
> for older TCPIP tools from multiple packages: the net-kit stuff,
> net-tools, iputils and others. Many of these are unmaintained. Then
> there's inetd and sysklog. If you use inetutils, you don't need almost
> all of that. It's just one package. This is a Slack build (but not a
> SlackBuild) for Slackware Current (but likely works on 15).

The manpage looks like Slackware provides an old BSD inetd version.

Dunno why.

-- 
Gruß
Marco

Spam bitte an abfalleimer2001@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#35612

On Sun, 31 May 2026 19:36:24 +0200, Marco Moock wrote:
> The manpage looks like Slackware provides an old BSD inetd version.

Yes, in /usr/doc/inetd-1.79s/README you can see that the "s" in the 
version string probably means "Slackware" as Patrick Volkerding has made 
som modifications.

regards Henrik

[toc] | [prev] | [next] | [standalone]

#35609

On 2026-05-30, jayjwa wrote:

> Note no setruid:
> -rwxr-xr-x   1 root   root        60632 May 30 14:44  traceroute*
> -rwxr-xr-x   1 root   root       145368 May 30 14:44  telnet*
> -rwxr-xr-x   1 root   root        68560 May 30 14:44  talk*
> -rwxr-xr-x   1 root   root        56400 May 30 14:44  rsh*
> -rwxr-xr-x   1 root   root        60752 May 30 14:44  rlogin*
> -rwxr-xr-x   1 root   root        56464 May 30 14:44  rexec*
> -rwxr-xr-x   1 root   root        64696 May 30 14:44  rcp*
> -rwxr-xr-x   1 root   root        65528 May 30 14:44  ping6*
> -rwxr-xr-x   1 root   root        74648 May 30 14:44  ping*
> -rwxr-xr-x   1 root   root       136920 May 30 14:44  ftp*
> -rwxr-xr-x   1 root   root        55896 May 30 14:44  dnsdomainname*

Some of these utilities don't really serve much use on a modern
system, so I would expect that most folks would simply not install
them.  Of those you list that are found on my systems, consider for
an alternative approach to mitigating the setuid risks (this is on
a Slackware-15.0 system):

   -rwxr-xr-x 1 root system 23K Feb 13  2021 /bin/dnsdomainname (*)
   -rwxr-xr-x 1 root system 92K Feb 13  2021 /bin/ftp
   -rwxr-xr-x 1 root system 32K Feb 13  2021 /usr/X11R6/bin/talk
   ---s--x--- 1 root users  64K Feb 13  2021 /usr/X11R6/bin/traceroute
   ---s--x--- 1 root users  76K Dec 16  2021 /bin/ping6         (*)
   ---s--x--- 1 root users  76K Dec 16  2021 /bin/ping          (*)
   -rwxr-xr-x 1 root system 94K Feb 28 19:13 /bin/telnet

(*) noting that /bin/dnsdomainname symlinks to hostname, and
    /bin/ping6 symlinks to ping; these are the permissions after
    unravelling those symlinks.

Those in that list that aren't setuid, I believe are shipped from
Slackware that way.  Those that are setuid are deliberately set to not
be readable, and although that alone doesn't solve any vulnerabilities,
in practice it does help to mitigate those whose exploits depend on
altering a copy of a setuid program.

I don't wish to diminish your contribution in any way, but I do hope to
present a potential alternate approach.  Interestingly, I was intending
to suggest that my approach mught be "closer to 'stock Slackware'",
but I'm left wondering "is it?"  On the one hand, I deliberately don't
install some of the packages that you're suggesting would be replaced,
while adjusting file permissions on some files that do get installed.
On the other hand you're suggesting to simply replace some packages
(and portions of packages) with a single package, making use of
Linux capabilities to negate the need to adjust any file permissions.
It's hard to say that either approach is closer to "stock Slackware",
or that either is really "simpler", yet they both accomplish their
intended missions to reduce the likelihood of system compromise by
exploiting setuid binaries.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web