Re: [zones-discuss] Code Review for 6613349 setuid not allowed message could be more useful
On Fri, Nov 14, 2008 at 11:21 AM, casper@sun.com wrote: On Thu, Nov 13, 2008 at 3:05 AM, casper@sun.com wrote: Originally I did that, but there was concern v_path might not always be correct (or available) (such as renames or with hard links IIRC), and so might generate a confusing message in those situations. I wasn't aware of any mechanism that could take exec_file or the vnode and generate a nice canonical pathname that didn't suffer from renaming or hard link issues, so the mountpoint was chosen instead. I think ideally it'd be nice to have both (in case the offending binary is deleted, you can still figure out where it took place). There are a few renamings we need to fix in the fs code; there's code which interprets v_path and beautifies like we use for /proc. Then you either get proper path or no answer. Typically, though, because your inside exec you MUST have translated the pathname. Doing a little digging through the /proc code a few minutes ago, does this mean you're suggesting using vnodetopath() ( http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath ) and using that if it returns a non-NULL value (which it sounds like it always should)? I don't think there's a 100% guarantee, but I can't of the top of my head see where it not work. I would, however, make sure that you handle a failure of the function. Casper Reviving things (now that I have a bit more time), http://cr.opensolaris.org/~jbk/suid has the updated changes. I'm not sure how to force a failure of vnodetopath() to test that code path, but aside from that everything tested ok. For full disclosure, I've only tested this on x86 (no sparc boxes I can touch to test on there). It was tested both in and outside of a zone. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code Review for 6613349 setuid not allowed message could be more useful
On Thu, Nov 13, 2008 at 3:05 AM, [EMAIL PROTECTED] wrote: Originally I did that, but there was concern v_path might not always be correct (or available) (such as renames or with hard links IIRC), and so might generate a confusing message in those situations. I wasn't aware of any mechanism that could take exec_file or the vnode and generate a nice canonical pathname that didn't suffer from renaming or hard link issues, so the mountpoint was chosen instead. I think ideally it'd be nice to have both (in case the offending binary is deleted, you can still figure out where it took place). There are a few renamings we need to fix in the fs code; there's code which interprets v_path and beautifies like we use for /proc. Then you either get proper path or no answer. Typically, though, because your inside exec you MUST have translated the pathname. Doing a little digging through the /proc code a few minutes ago, does this mean you're suggesting using vnodetopath() ( http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/lookup.c#vnodetopath ) and using that if it returns a non-NULL value (which it sounds like it always should)? I don't think there's a 100% guarantee, but I can't of the top of my head see where it not work. I would, however, make sure that you handle a failure of the function. Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code Review for 6613349 setuid not allowed message could be more useful
I'm looking for reviewers for '6613349 setuid not allowed message could be more useful'. I've tested it on a b101 system without any issues. It's pretty straightforward (and small) -- just modifying the message to display the filesystem path (instead of the device number) and making it zone aware (which is why I included security-discuss and zones-discuss). Why do you use the mntpnt and why not the vp-v_path? Casper ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Code Review for 6613349 setuid not allowed message could be more useful
On Wed, Nov 12, 2008 at 12:46 PM, [EMAIL PROTECTED] wrote: I'm looking for reviewers for '6613349 setuid not allowed message could be more useful'. I've tested it on a b101 system without any issues. It's pretty straightforward (and small) -- just modifying the message to display the filesystem path (instead of the device number) and making it zone aware (which is why I included security-discuss and zones-discuss). Why do you use the mntpnt and why not the vp-v_path? Casper Originally I did that, but there was concern v_path might not always be correct (or available) (such as renames or with hard links IIRC), and so might generate a confusing message in those situations. I wasn't aware of any mechanism that could take exec_file or the vnode and generate a nice canonical pathname that didn't suffer from renaming or hard link issues, so the mountpoint was chosen instead. I think ideally it'd be nice to have both (in case the offending binary is deleted, you can still figure out where it took place). ___ zones-discuss mailing list zones-discuss@opensolaris.org
