[request-sponsor] Request Sponsor for 6613349
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))) {
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, 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.
[request-sponsor] Request Sponsor for 6613349
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,
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.
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?
Casper
[request-sponsor] Request Sponsor for 6613349
On Fri, 25 Jan 2008, Jason King wrote: I'm going to try again... I'd like to request a sponsor for 6613349 Jason, I guess many people just ignore bugs for which no synopsis was provided. It's quite tiring to look up every such bug that goes through this alias when it's so easy to put it there. Btw: 6613349 setuid not allowed message could be more useful cheers, J. -- Jan Pechanec
[request-sponsor] Request Sponsor for 6613349
I'm going to try again... I'd like to request a sponsor for 6613349 My contributor # is 0137
[request-sponsor] Request Sponsor for 6613349
I'd like to get a sponsor for 6613349 -- setuid not allowed message could be more useful.
