On 2015-07-09 22:01:01, Theo de Raadt <dera...@cvs.openbsd.org> wrote:
> > On Thu, 09 Jul 2015 18:18:37 -0700, Edgar Pettijohn
> > <ed...@pettijohn-web.com> wrote:
> >
> > > # chflags schg /etc/resolv.conf
> > >
> > > Just keep in mind you have to go to single user mode to undo the above.
> >
> > That's an interesting workaround I hadn't considered. The problem is that
> > this setting must be deployed via an Ansible playbook, so single user mode
> > is out.
>
> The 4.4BSD chflags model of "security" on inodes is unmaintained, and the
> utilitization of this is not realized OpenBSD.
>
> To be honest, I doubt any of us see much benefit in it, relative to other
> features of the system. When you are holed, a few file changes + a reboot
> can undo it, voila, noone would ever notice.
>
> I don't think it is more than a gimmick.
>
> If you use it, you really are on your own. To my knowledge, noone in
> the development group has seriously trialed/used it in years.
>
FWIW, one case where I find chflags useful is in the following scenario:
Some programs (mostly ones in the ports/games hierarchy) are not completely
stable when coupled with in-game, third-party add-ons, and tend to crash
occasionally.
On my old, circa 2005 systems, writing out a ~1.5 GB core file probabaly
takes about 30-120 seconds to complete (I never actually timed it, but it
certainly takes long enough to notice), by which time upon rejoining the
game most people have already left. By doing:
% rm game.core
% touch game.core
% chflags uchg game.core
It prevents the game from being able to write a core file, and allows me
to restart it and rejoin the game quickly.
Is it OpenBSD's fault these games crash from time to time? No, it's
either the main developers of the game, or the third-party add-on
writers who are probably doing something with memory management that
OpenBSD's malloc rightly rejects.
Is this an extremely marginal usage case where I may be the only one
using it like this? Yes, and possibly (in that order).
Should I be sending these backtraces upstream instead of silently tolerating
them? Probably, but they happen infrequently enough now that it's really
not that difficult to just re-launch and re-join the game when it does happen.
I don't use chflags for anything security related, and I could probably
find another way to prevent programs from dumping core if I spent the time
to look, but this works for me so I use it. From searching around at this
very moment, it looks like tweaking "ulimit -c" might also accomplish the
same goal.
Someone could probably insert a quote here about features being used for
purposes the original developers never even considered when they were first
implemented.
When you say that the chflags model is "unmaintained" I hear, "this may
possibly be removed at some point in the future" and "if it breaks anything,
you get to keep all the pieces". While I find it useful for my particular
usage case, I won't complain if it's removed since I trust that the OpenBSD
developers remove code for good reason (being broken, buggy, or having
other potentially negative effects).
That being said, I do find it useful in my (esoteric) case, though as I
said, these games have actually become a lot more stable over the years
so they actually don't crash all that often anymore.
--
Bryan
