>> My personal stance on this one is that it'd be a good idea to report the
>> mountpoint instead of the device major/minor. What did you have in mind ?
>Here's what I was thinking:
>--- a/usr/src/uts/common/os/exec.c      Mon Oct 08 20:24:50 2007 -0700
>+++ b/usr/src/uts/common/os/exec.c      Fri Oct 05 17:02:44 2007 -0600
>@@ -604,8 +604,12 @@ gexec(
>        if ((vp->v_vfsp->vfs_flag & VFS_NOSETUID) &&
>            (vattr.va_mode & (VSUID|VSGID))) {
>                cmn_err(CE_NOTE,
>-                   "!%s, uid %d: setuid execution not allowed, dev=%lx",
>-                   exec_file, cred->cr_uid, vp->v_vfsp->vfs_dev);
>+                       "zone: %s, uid %d: setuid execution not allowed, "
>+                       "file=%s",
>+                       cred->cr_zone->zone_name, cred->cr_uid, 
>I wasn't sure what things in the vnode might be valid for use in this
>context (i.e. would vp->v_vfsp->vfs_mntpt be safe to deference),
>however the args struct from all appearances seems to be safe.  For
>me, I'm more interested in knowing what was being run (or attempted at
>least).  exec_file appears (if I'm understanding the code correctly)
>to be the unresolved path, while args->pathname appears to be the
>resolved pathname.

Note that args->pathname may be an simple relative pathname.

Why have you removed the initial '!' from the message?

It has special meaning to cmn_err.

>I was also wondering if perhaps instead of cmn_err, if it should be
>zcmn_err instead -- seems like it should go to the zone's console
>where the suid violation occurred instead of always to the global zone
>(or perhaps both).
>If you have any suggestions on that, please let me know (though I'm
>guessing it'd be better to move the discussion to a different list if
>more discussion is needed).  If not, I'll try to get you a build log
>from that sometime in the next few days.

May I suggest opensolaris-code?


Reply via email to