[COFF] A little networking tool to reduce having to run emulators with privilege

[gtaylor at tnetconsulting.net (Grant Taylor)]

On 9/23/20 5:50 PM, Steffen Nurpmeso wrote:
> Hello.

Hi,

> Sorry for the late reply, very last summer day with cold and rainy 
> days to come, and then i really turned on the TV on a non-Sunday 
> for the first time for long, to watch the German film "Gundermann", 
> which i had on my list ever since i have heard from it.

No apology necessary.

That's one of the wonderful things about email.  It's their waiting for 
it to be convenient for you.  ;-)

> This thread also gives me the feeling of being twisted and wrapped, 
> .. but you know, feelings, pah.
~chuckle~

> This i have never used, i do not have it installed.  But you mention 
> it -- what i did not understand is why it is not "simply" made a 
> policy that when you want to create a software bridge device, you 
> can create it.

Either I'm having trouble unpacking that or otherwise not understanding it.

You can create the bridge any time that you want to.  (Presuming that 
the kernel dependencies have been met.)

Or are you making reference to you shouldn't be able to create the 
bridge if it won't work?

> In the end i expect the problem to manifest in only a few bytes 
> of data?

How many byte of data are you able to send from the system behind the 
bridge behind the WiFi NIC that doesn't want to play nicely?

> Well i never had doubts there are some technical reasons, i just did 
> not know them, and there were no nice error messages nor documentation 
> of the problem.  But given that it _does_ work for some drivers i was 
> also sure that the actual problem is more of a notational sort, so 
> to say, and then i did not understand why the creation of a software 
> bridge does not take appropriate steps to make this happen.

Because the behavior that I'm talking about is atypical, almost never 
needed, and requires additional kernel capabilities.

There is also no good way for a system to know if the hack that I'm 
talking about needs to be done or not.

Even more importantly, if this hack was automatically done, it would 
mess up the most common use case for bridges or at least cause 
unexpected behavior.

> I could say "heck, but if ..
> 
> then it can be done".

Bridging does work with wireless in so far as the bridged frame is 
handed to the wireless NIC.

It's the wireless NIC that fails to do things properly.

Is it the light switch or the light bulb's fault that the light does not 
come on when there is no power to the building?

> But i do not.

But in a way you did.  ;-)

> Well if i had the time and motivation i surely could dive into kernel 
> sources and look around, and maybe even get it (done).  But i have 
> so much to do with what other people would call livestock but i call 
> friends, for example, so it seems i am too old and hackneyed to get 
> that job done.

Fair enough.  To each their own.

Chances are that your friends are there for you when the power is out.

> yeah.
> 
> Yes, this is all ssh/scp communication, and that the script handles 
> SSH came with that veth/bridge rewrite, before everything simply had 
> to be typed.  And so i need a name or a fixed IP in .ssh/known_hosts. 
> Here i have both now, without much straining.
> 
> It has to be said that Linux should really offer some kind of 
> setproctitle(2), more and more BSD programs use it to give sense to 
> ps(1) output of privilege-separated programs, and the compatibility 
> code using PR_SET_MM_MAP of prctl(2) after reading and parsing 
> /proc/self/stat is, well, immense effort.

Okay.

I'm guessing we're running / ran different versions of dhcpcd.  I'm used 
to one process per instance.  Hence why I thought you were running 
multiple instances of it.  (Along with the thought that you were running 
multiple network namespaces.)

> No.  No, that is really overkill, i am not a student with bad body 
> hygiene having fun with software or something.  It is annoying enough 
> that you ever and always again settle on a "that is a good status quo" 
> just to find out the next day that doing it all anew would possibly 
> improve the situation.  No.

Indeed.  If it does what you want and you're satisfied with it, the more 
power to you.

> That HostAP software or how it is named, doesn't it deal with this the 
> right way?  I seem to have read this is possible.  Never tried this.

I have run HostAP.  It's fairly nice and feature complete.  However, 
HostAP has requirements of wireless cards that play nice with things. 
Even the nicest software can't realistically overcome hardware limitations.

> Imho "bridge" should do this by itself automatically.

See above.  What I'm suggesting with EBTables is way beyond what bridges 
should do.  In fact, any bridge that does it is not behaving like a 
bridge.  It's behaving like something completely different.

Bridges learn who's on what side and doesn't pass something across if it 
knows the destination is on the side the message is from.  There's no 
point in sending it across.

What I'm talking about doing is effectively the bridge lying and 
claiming that everybody on the other side is the bridge.

So, no, bridges should not do what I'm pontificating automatically.

> Well you could look into software like "containers", you could read
> 
>    If cgroup support, the memory controller and the pids controller
>    are compiled into the kernel, a mounted cgroup2 filesystem can
>    be used to apply memory and process-count limits to a container
>    as it is started. For example, the shell script
> 
>      #!/bin/sh -e
>      echo +memory +pids >/sys/fs/cgroup/cgroup.subtree_control
>      mkdir /sys/fs/cgroup/mycontainer
>      echo $$ >/sys/fs/cgroup/mycontainer/tasks

Does this move the current running shell's PID ($$) into the mycontainer 
cgroup?

>      echo 2G >/sys/fs/cgroup/mycontainer/memory.high
>      echo 3G >/sys/fs/cgroup/mycontainer/memory.max
>      echo 2G >/sys/fs/cgroup/mycontainer/memory.swap.max
>      echo 256 >sys/fs/cgroup/mycontainer/pids.max

Setting parameters on the mycontainer cgroup.

Seems simple enough.

>      exec contain [...]

exec to replace the running shell with a new process while keeping the 
same PID.

>    See linux/kernel/Documentation/cgroup-v2.txt for detailed info
>    on the available controllers and configuration parameters.

I'll have to check that out.

That all seems simple enough.  It's definitely in line with the way that 
I do namespaces.

> But most of it can be done with unshare and nsenter.  For example the 
> super minimal ulinux project (a bit stale) has a box script which does, 
> among other things
> 
>    # shellcheck disable=SC2086
>    unshare \
>      --ipc \
>      --uts \
>      --pid \
>      --user \
>      --fork \
>      --mount \
>      --mount-proc \
>      --map-root-user \
>      /usr/sbin/chroot "$tmpc/root" \
>        /usr/bin/env -i $BOX_ENV /bin/sh -c "source /init; $*"

That all looks like typical namespace manipulation.  I don't see the 
relation to cgroups.

> It could do nice things like
> 
>    setup_tmpc() {
>      mkdir -p "$tmpc/root" "$tmpc/storage" "$tmpc/work"
>      mount -t overlay \
>        -o upperdir="$tmpc/storage,lowerdir=/,workdir=$tmpc/work" \
>        overlayfs "$tmpc/root"
> 
> I am really interested, but am too lazy to convert the scripts so 
> that this "distribution" (almost kernel-only) can be build without 
> docker etc.

Fair.

Though, I don't see any reason why you can't have a minimal version of 
the distribution that you're running things on now.  Thus there wouldn't 
be any porting.

> I personally am always astonished when i have contact with Plan9.

I've not done anything with Plan9.  Though I have been impressed by what 
I've heard others say and read what they write.

> I cannot really use it, i am too used to BSD/Linux, and some things 
> drive me insane (network configuration etc. is so spreaded).  But i 
> am subscribed to the MLs ever since i have been pointed to Plan9 and 
> always wonder when problem solutions happen to happen, how it is done.

I'm not sure what "MLs" are (is?) in this context.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200923/5f3991d3/attachment.bin>