• I'm not using a nano-install here, so I'm not really sure of the answer or filing system layouts involved.

    What sorts of activities require a temporary switch from conf_mount_ro() to conf_mount_rw()?

  • Banned

    Anything that needs to write on the RO-mounted slice.

  • If you want to write anything under "/" root filesystem or "/cf" where the config is stored (e.g. saving something like RRD or DHCP leases data or some package data during shutdown).
    On nanoBSD /var and /tmp are already always RW memory disks.

  • Can someone look at diag_packet_capture.php and let me know which operations are doing so? I assume some of the system calls might be, but it's not clear. Is it purely to allow writing of the packetcapture.cap files (surely should be on /var or /tmp not /root?), or is there something else?

  • Banned

    It's writing to /root/packetcapture.cap; obviously you need it writeable…

  • Yes, got that from Phil's comment. Does anything else on that page need RW access or just the cap file writing? Is there a reason the (presumably temporary) capture files are going to /root and not (say) /tmp or /var? Could they perhaps go just as well in (say) /var/capfile or similar, which doesn't need RW access and avoids permanent storing of captured traffic data (that might not always be desirable)?

  • Banned

    Probably because the packet captures are kinda sensitive contents? What problem are you trying to solve here???

  • Hmm.  I'm not convinced by that - after all, any location can have appropriate permissions defined, so a subdir on /var shouldn't inevitably be any less secure than /root.  It's not inherently so. It's just a matter of suitable permissions.

    As to the problem - a long-ish duration capture of an hour or so (for some network glitch to recur) means long-ish duration RW access with the RO partitions held open for that time.  That's less than desirable. If they were meant to be open long-ish term they would be mounted RW from the start, not just switched briefly as needed. Also (and this I'm more hazy about) if the browser window or session closes, the capture continues in the background, but is there a guarantee the remount back to RO will always be done in every case, if the connection is dropped or the final rendered capture never gets sent to stdout?

    Also it's not clear why general diagnostic info like a capture file, would be put to /root as it's not inherently associated with the /root account. If the answer is sensitivity then a combination of a less permanent drive plus suitable permissions is still better.

    When all said, a capture is intended to be like RRD, a temp-use file (anything else and it gets downloaded). The simplest solution would be a place on the file system that's appropriately secured by permissions, but (unlike /root) doesn't require RW conf access switching to save the cap file. Maybe /var/capfiles or something, with tighter permissions than most /var directories? Doesn't need to be at all complicated or change anything, but I just don't see a benefit to having them stored on /root and reasonable reasons to think elsewhere could work better.

  • Banned

    With your longish packet capture, you'll fill up the ramdisks and make the box crash. After reboot, your longish packet capture will have vanished. That'll be definity wonderful. Sigh. Really. There's nothing like inventing issues when there are none.

  • That's.. remarkably unhelpful. If the target is capturing glitches, or packets that are only occasional, they'll define capture filters that exclude the 99.999% of stuff they aren't interested in.  They might also have an idea of the likely capture size and free ram/disk size (and write speed). Or the traffic levels might be low or sporadic.

    If you're feeling cynical and disparaging today, let someone else answer. Meantime, back to the question last asked, and it'd be good not to derail a helpful thread so far.

  • The packet capture page goes to rw because it saves the pcap in /root/. It keeps it there because there is significantly more space in /root/ than the RAM disks, and if you exhaust the disk space on the RAM disks, worse things will happen than if you exhaust / partition's space.

  • Thanks :) Perfect sense, now it's explained!

    And thus one learns New Things…  ::)

Log in to reply