Re: savecore: default to -N /dev/ksyms?

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I'm not sure I'd call it an objection, really, but-- are you sure
>> access() is the right thing in view of its behaviour in set-id
>> processes?  Especially for libkvm?
> It's a hard-coded path in /dev.  Unless you are doing really strange
> things, users don't have control over that, right?

I'm not so much concerned about what users have the ability to meddle
with as programs unexpectedly refusing to work when made set-id.

"Unix does not stop you from doing stupid things because that would
also stop you from doing clever things".  Is it acceptable for libkvm
to mysteriously break when someone tries to do a clever thing?
Postulating a system where /dev/ksyms is unreadable for some user (some
kind of really stringent least-privilege setup, maybe - this is one
part of the "clever thing") but the admin wants that user to run some
specific program, and makes the program set-id so it can access
/dev/ksyms (the other part) - only to find that it doesn't work,
because libkvm uses access() to probe /dev/ksyms.

I think a much righter tack to take is to try to use /dev/ksyms, with
the fallback mechanism (whatever it is for the case in question) used
when the attempt to use /dev/ksyms doesn't work.  This also
automatically fixes the case where /dev/ksyms exists and is readable
according to permissions but, for whatever reason, fails in open() (or
nlist() or whatever, for a thorough implementation).

The major downside I see is that the patches would probably be more
intrusive.  And, since I'm not doing it, this is all armchair
quarterbacking, which is at least in part why I phrased my first email
as I did.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B