On Jan 28, 2008 6:11 AM,  <Frank.Hofmann at sun.com> wrote:
> On Fri, 25 Jan 2008, Jason King wrote:
> > I'm going to try again...
> >
> > I'd like to request a sponsor for 6613349
> > My contributor # is 0137
> Hi Jason,
> has anyone offered to sponsor you on that one yet ?

Not yet

> If not I'd be willing to do it. Have you got diffs + build logs already ?

I seem to have cleaned out my build logs when I originally did this
(I'll try to rebuild sometime in the next few days)

> 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))) {
-                   "!%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, args->pathname);

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.

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.

> Thx,
> FrankH.

Reply via email to