LWN: Comments on "A crop of new capabilities"

A crop of new capabilities

geert — Tue, 16 Jun 2020 13:55:14 +0000

I use "screen -dRR -S <sessionname> ..." all the time, from a script that knows how to connect to whatever target board I specify.

There is one caveat though: if a session name is an abbreviation of another session name, and the session with the shorter name doesn't exist yet, then screen will happily connect to the (wrong) session with the longer name instead. Once the session has been created, everything works as expected, though.
Solution: create your sessions in the right order, so they never match an existing one.

A crop of new capabilities

Jandar — Fri, 12 Jun 2020 02:24:36 +0000

> You can do that with screen, too.

I was going to say: it doesn't work that way, but I tested it before commenting. In reality it does work.

The only explanation I have is, that the manual shows contradicting usages.

1) from the Synopsis:
screen -r [[pid.]tty[.host]]
2) from the section COMMAND-LINE OPTIONS:
-r [pid.tty.host]
-r sessionowner/[pid.tty.host]
In 2) the pid seems to be not optional and the sessionname from -S sessionname
only substitutes tty.host. The text description for -r says "prefix of [pid.]tty.host" so pid seems optional.

I have never tested if screen -r sessionname works, I've always assumed pid is mandatory. *facepalm*

A crop of new capabilities

kmweber — Thu, 11 Jun 2020 23:24:34 +0000

> Or you could use tmux and the you get access to named sessions/sockets

You can do that with screen, too.

A crop of new capabilities

Jandar — Thu, 11 Jun 2020 20:41:38 +0000

> This probably works much better when pids are small (when uptime is low).

The uptime doesn't factor in. The production systems of our customers mostly have max-pid of 64k with a high uptime. The pid wraps around after a few hours to a few days. So if someone other starts a screen from the shared admin-account it gets a pid nearly at random. The pids starting from 1 to 5 are from a set of 11111 numbers (disregarding special pids like 1) and pids starting from 7 to 9 are from a set of 1111.

while [[ $(readlink /proc/self) != 9* ]]; do :; done && screen -S Jandar

As normally at most a handful screen are running, the chance to have 9* exclusively for myself is high because no workmate uses the shell-prompt to type in loops. Probability with 5 other screen = (1-1111/2^16)^5 = .91807.

A crop of new capabilities

mathstuf — Thu, 11 Jun 2020 18:13:03 +0000

A true hacker's hack. Or you could use tmux and the you get access to named sessions/sockets ;) .

This probably works much better when pids are small (when uptime is low). Now to get such a pid after you already have pid 1000000 spawned, your process comet probably takes a non-negligible amount of time. And then you're stuck with another million or so pids until it is unique again.

A crop of new capabilities

Jandar — Thu, 11 Jun 2020 16:17:22 +0000

I have long running (multiple months) screen sessions on some production servers to which I connect frequently. To connect to screen you have to specify the unique beginning of the screens pid. All pids beginning with a higher digit as the begin of max-pid are 10 times rarer than those with a lower digit. If I get a screen with pid 9* it's normally sufficient to type 'screen -r 9' to reconnect.

Do you have to make many guesses about what I do when starting the screen? ;-)

A crop of new capabilities

zdzichu — Thu, 11 Jun 2020 07:09:34 +0000

For example, RPM packages define metadata about files shipped in the package. Owner, permission, ACL, xattrs, capabilities etc. When package is installed, all those attributes are set to match.
This look like following in RPM .spec file:

%attr(0755,root,root) %caps(cap_net_raw=p) %{_bindir}/arping

This way “arping” command can be run without special privileges. Some more information: https://fedoraproject.org/wiki/Features/RemoveSETUID

A crop of new capabilities

hendry — Thu, 11 Jun 2020 02:55:44 +0000

I don't quite understand how binaries are distributed by Linux distributions with these capabilities.

Are any distros leveraging this?

A crop of new capabilities

NYKevin — Wed, 10 Jun 2020 04:05:22 +0000

Obviously, you're supposed to send them a SIGSEGV with kill(2), and hope whoever's responsible for that binary never figures out their impossible-to-reproduce segfault bug.

I mean, that's almost as sensible as some of the other suggestions in the article, right?

A crop of new capabilities

kevincox — Tue, 09 Jun 2020 19:28:28 +0000

At a minimum it seems like a reasonable demonstration that requiring special privileges to perform this is not an effective mitigation.

A crop of new capabilities

Cyberax — Tue, 09 Jun 2020 00:24:15 +0000

Each PID namespace starts PIDs from 1. So this shouldn't be an issue.

A crop of new capabilities

nickodell — Tue, 09 Jun 2020 00:15:53 +0000

>Setting the ID of a new process is possible with clone3(), but this feature is not available to unprivileged processes. The ability to create processes with a chosen ID would make a number of attacks easier, so ID setting is restricted to processes with, of course, CAP_SYS_ADMIN. Administrators tend to balk at handing out that capability, so CRIU users have been resorting to a number of workarounds; Reber listed a few that vary from the reasonable to the appalling:
So what are you supposed to do if some other process starts using that PID?

I don't get what the issue is with using a PID namespace. It seems like it fixes both the permissions issue and the collision issue.

A crop of new capabilities

NYKevin — Mon, 08 Jun 2020 23:37:17 +0000

> Some users run the equivalent of a fork bomb, quickly creating (and killing) processes to cycle through the process-ID space up to the desired value.

Wait, what???

Are people actually doing that in production, or is it one of those "gee willikers, look what I can do" GitHub repositories?

A crop of new capabilities

roc — Mon, 08 Jun 2020 20:38:30 +0000

I wonder what the use-cases are for CRIU that require putting a migrated process in the same namespaces as other non-migrated processes.

When it's OK to run the migrated process in its own namespaces, i.e. a container, there isn't really a problem because the migrated process can have (or at least start with) CAP_SYS_ADMIN in those namespaces.