At Tue, 6 Sep 2011 06:39:18 +0000 (UTC), mlelstv%serpens.de@localhost (Michael
van Elst) wrote:
Subject: Re: "Real programs dump core"
>
> hf%spg.tu-darmstadt.de@localhost (Hauke Fath) writes:
>
> >>
> >> 13 EACCES Permission denied. An attempt was made to access a file in a
> >> way forbidden by its file access permissions.
>
> >That's tough to decipher without a core.
>
> I don't think a core tells you the current directory of the process.
I have patches to make the kernel log the attempted directory name. I
find this to be absolutely essential information that I cannot do
without. :-)
I can supply them on request. I think they may already be in a rather
dated and closed PR, and I think I've failed to follow up with a new PR
with cleaner patches as I was requested to do long ago. (my current
patches are against the netbsd-5 branch -- should I send-pr them?)
> EFBIG is also reported when the dump would exceed the core dump limit.
>
> /*
> * Refuse to core if the data + stack + user size is larger than
> * the core dump limit. XXX THIS IS WRONG, because of mapped
> * data.
> */
> if (USPACE + ctob(vm->vm_dsize + vm->vm_ssize) >=
> p->p_rlimit[RLIMIT_CORE].rlim_cur) {
> error = EFBIG; /* better error code? */
> [...]
> }
Indeed, and I think that's the right error code to use for that case
(i.e. the comment above is out-dated), but other error codes in the core
dumper are very poor. I change them like this: (this includes tiny
bits of the above mentioned patch, and I think this may also already be
in an old PR too)
Index: sys/kern/kern_core.c
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/sys/kern/kern_core.c,v
retrieving revision 1.12
diff -u -r1.12 kern_core.c
--- sys/kern/kern_core.c 24 Apr 2008 18:39:23 -0000 1.12
+++ sys/kern/kern_core.c 5 Jul 2011 00:19:38 -0000
@@ -55,7 +55,7 @@
#if !defined(COREDUMP)
int
-coredump(struct lwp *l, const char *pattern)
+coredump(struct lwp *l, const char *pattern, char *corename)
{
return (ENOSYS);
@@ -73,11 +73,14 @@
static int coredump_buildname(struct proc *, char *, const char *, size_t);
/*
- * Dump core, into a file named "progname.core" or "core" (depending on the
- * value of shortcorename), unless the process was setuid/setgid.
+ * Dump core, into a file name created from 'pattern' (unless the process was
+ * setuid/setgid, in which case if security_setidcore_dump is also true then
+ * security_setidcore_path is used as the file name pattern).
+ *
+ * XXX maybe logging should go here instead of all callers? (need better API)
*/
int
-coredump(struct lwp *l, const char *pattern)
+coredump(struct lwp *l, const char *pattern, char *corename)
{
struct vnode *vp;
struct proc *p;
@@ -91,6 +94,10 @@
char *name;
name = PNBUF_GET();
+ if (name == NULL) {
+ error = ENOMEM;
+ goto done;
+ }
p = l->l_proc;
vm = p->p_vmspace;
@@ -105,7 +112,7 @@
*/
if (USPACE + ctob(vm->vm_dsize + vm->vm_ssize) >=
p->p_rlimit[RLIMIT_CORE].rlim_cur) {
- error = EFBIG; /* better error code? */
+ error = EFBIG;
mutex_exit(p->p_lock);
mutex_exit(proc_lock);
goto done;
@@ -130,7 +137,7 @@
vp = p->p_cwdi->cwdi_cdir;
if (vp->v_mount == NULL ||
(vp->v_mount->mnt_flag & MNT_NOCOREDUMP) != 0) {
- error = EPERM;
+ error = ENXIO;
mutex_exit(p->p_lock);
mutex_exit(proc_lock);
goto done;
@@ -142,7 +149,7 @@
*/
if (p->p_flag & PK_SUGID) {
if (!security_setidcore_dump) {
- error = EPERM;
+ error = EAUTH;
mutex_exit(p->p_lock);
mutex_exit(proc_lock);
goto done;
@@ -155,6 +162,7 @@
mutex_enter(&lim->pl_lock);
if (pattern == NULL)
pattern = lim->pl_corename;
+ KASSERT(pattern); /* otherwise name is "", and what will
vn_open() do? */
error = coredump_buildname(p, name, pattern, MAXPATHLEN);
mutex_exit(&lim->pl_lock);
mutex_exit(p->p_lock);
@@ -198,8 +206,11 @@
if (error == 0)
error = error1;
done:
- if (name != NULL)
+ if (name != NULL) {
+ if (corename)
+ strcpy(corename, name);
PNBUF_PUT(name);
+ }
return error;
}
Totally as an off-colour aside: is sudo a "real" program? I've always
considered it to be a rather horrid abomination and quite a big risk,
even if it were not so regularly buggy and crashy. Even implementing
the "rootauth" group can significantly increase the risk for a system in
some of the same circumstances, though perhaps not quite as bad, and
perhaps in combination with S/Key I think it can even be much more
secure. Admin user accounts are so poorly understood as risks. Any
real system threat will focus on them and never directly on the root
account.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpB8bAvBmyYM.pgp
Description: PGP signature