=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 title: Boundaries, Amirite?
 date: 2025-09-22 16:22:00
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

My lab computers are scheduled to automatically shut down between
classes.

While it could be obvious _why_ this is the case, it ultimately
ensures that accounts aren't left logged in and hogging resources
for the next class, power consumption is reduced, and (most
importantly) the room isn't a hotbox every single morning.

What I *don't* shut the machines down for is to prevent students
from connecting to them remotely after school hours. Because the
machines are shut down anyway, preventing ingress after hours
wasn't something that was really on my radar.

Well... last week I learned to never underestimate the ingenuity of
a teenager with a computer, a still-developing prefrontal cortex,
and too much time on their hands.

This past week, one of my students figured out that if they set a
userspace cron job to spam the `shutdown -c` command the second
school gets out, they can keep the machine running indefinitely
without raising any flags with any other students using that same
computer. For the curious, here is the script they wrote:

```bash
#!/bin/bash

LOGFILE="/home/USERNAME/laston.txt"

while true; do
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] Running shutdown -c"
    echo 'Please have mercy!'
    echo "I cannot shutdown since users are online, but I will do
house-keeping when I'm finished. See you o/"
    shutdown -c >> "$LOGFILE" 2>&1
    sleep 1
done
```

I actually admire the creativity here. They set up a cron job (in
their *own* user account, meaning no root access required) to run
this script every minute. The script itself runs indefinitely, so
the cron job is effectively a no-op after the first time it runs,
and they even added logging to a file in their home directory so
they could see that it was working.

What they did next, though, was set up another cron job to connect
to a tailscale [0] network and start a VNC server immediately after
reboot (both of which were *also* userspace services, meaning no
root access required).

Why might a student want to do this, you ask?

So they could work on their coding assignments after school without
having to transfer files around. Via Git. That industry-standard
tool that I teach them to use for exactly this purpose. I'd be
impressed if it weren't for the lack of personal reflection as to
whether or not what they were doing was a *good* idea and not just
a *fun* one.

All of this is a good reminder that there's a fine line between
_guardrails_ and _boundaries_.

I didn't set guardrails to prevent these activities, so they
cobbled together something that *definitely* violates my
established boundaries (and the actual ethics contract they
signed), but there was no ill intent so it's been a good reminder
for me in the importance of clear communication (*turns out, if
students don't know what "ingress" means, they can't effectively
follow a rule that disallows it without explicit permission*).

Talks have been had and boundaries have been *firmly* reestablished
(I hope), but I also made sure to add more hard guardrails to
commands that 99% of my students were responsible enough not to
abuse (in case you are curious, I updated the firewall to limit
ingress to only the lab IPs—which means that some future
client-server labs will be more limited—and I disabled all personal
crontabs thanks to the cron.allow [1] file, which I was previously
unaware of).

Anything else I seem to be missing?

It's been well over 15 years since I managed a Linux lab, so there
are probably some cobwebs in the "best practices" that still need
dusting off.

---
[0]: https://tailscale.com/
[1]: https://bash.cyberciti.biz/guide//etc/cron.allow
---


EOF