[Zope] [PATCH] dtml-comment doesn't? Please fix... ;-)
Andrew Kenneth Milton [EMAIL PROTECTED] wrote:
+---[ Kip Rugger ]--
|
| [snip]
|
| dtml-if "0"
| crap
| more crap
| dtml-if "0"
| Lots of crap
| /dtml-if
| /dtml-if
|
| by analogy with the common practice of #if 0 in C
Won't work, the container will still be parsed for correctness at 'save' time.
The problem isn't getting nested comments per se, we already have that.
The problem is to completely ignore the contents of the comment tag whilst
still allowing nested comments.
Th second part of the problem is that ChrisW(hinger) really wants it, but,
doesn't want to do what is necessary to do it. So the problem is simplified
to not actually doing anything except talking about doing it. d8)
Thankyou for playing d8)
Since I put my stupid foot into it, I just had to write the patch.
For penitence and to learn about DocumentTemplate.
This should let you nest dtml-comment arb stuff /dtml-comment
without any syntactical value being ascribed to the contents.
I am too new to Zope to know if this is even desirable :-) so I
just offer it as more of an amusement than anything else.
Patch against 2.2.1 source.
--- DT_String.py.orig Thu Aug 17 08:46:48 2000
+++ DT_String.pyThu Sep 7 22:27:42 2000
@@ -237,7 +237,11 @@
if s: result.append(s)
start=l+len(tag)
-if hasattr(command,'blockContinuations'):
+if command == Comment:
+start = self.parse_comment(text, start, result, tagre, tag, l,
+ command, args)
+
+elif hasattr(command,'blockContinuations'):
start=self.parse_block(text, start, result, tagre,
tag, l, args, command)
else:
@@ -280,7 +284,11 @@
try: tag, args, command, coname= self._parseTag(tagre,scommand,sa)
except ParseError, m: self.parse_error(m[0],m[1], text, l)
-if command:
+if command == Comment:
+start=l+len(tag)
+start = self.parse_comment(text, start, result, tagre, tag, l,
+ command, args)
+elif command:
start=l+len(tag)
if hasattr(command, 'blockContinuations'):
# New open tag. Need to find closing tag.
@@ -325,6 +333,35 @@
start=self.parse_close(text, start, tagre, tag, l,
command,args)
elif not coname: return start
+
+def parse_comment(self, text, start, result, tagre,
+stag, sloc, sargs, scommand):
+nest = 1
+while 1:
+
+l=tagre.search(text,start)
+if l 0: self.parse_error('No closing tag', stag, text, sloc)
+
+tag, name = tagre.group(0, 'name')
+start = l + len(tag)
+if name == 'comment':
+try:
+end = tagre.group('end')
+except:
+try:
+end = tagre.group('fmt')
+if end != ']': end = ''
+except:
+self.parse_error('Delimiter problems',
+ stag, text, sloc)
+if end == '':
+nest = nest + 1
+else:
+nest = nest - 1
+
+if nest == 0:
+start=self.skip_eol(text, start)
+return start
shared_globals__roles__=()
shared_globals={}
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Bill Anderson [EMAIL PROTECTED] wrote: Kip Rugger wrote: Chris McDonough [EMAIL PROTECTED] wrote: Aplogies for the ignorance, but can you maybe explain the concept of supplemental group ids and give an example of how the current unpatched behavior could be subverted? I can try... Supplemental gids are useful for allowing a user to belong to more than one group, or maybe to more than one project in normal parlance. This is normally effected by listing the uid opposite more than one group in /etc/group. The login process issues the initgroups(3) call to install these supplemental groups, which are inherited by all processes forked from the login shell. The problem is comes when you change user ids; for example what I saw with Zope (start -u nobody) was: before change after change = user id root nobody group idroot nobody sup id(s) root root Would you mind describing how you determine this? [/proc] $ cat /proc/90/status Name: junkbuster State: S (sleeping) Pid:90 PPid: 1 Uid:101 101 101 101 Gid:101 101 101 101 Groups: 101 -- supplemental groups VmSize: 1348 kB VmLck: 0 kB VmRSS: 436 kB VmData: 192 kB VmStk:84 kB VmExe:92 kB VmLib: 952 kB SigPnd: SigBlk: SigIgn: 80011006 SigCgt: CapInh: feff CapPrm: CapEff: On my machine 101 is uid and gid for nobody; as you can see junkbuster is correctly sandboxed. For unmodified Zope, you'll see a zero in the indicated line (or possibly several values if root belongs to several groups like `wheel' on your system). ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Andrew Kenneth Milton [EMAIL PROTECTED] wrote: | I saw this on Linux; supplemental groups come from the BSD tradition, | so you likely will find the same situation on *BSD, Solaris, etc. Sorry I missed the start of the thread, but, I can weigh in on this point. Using -u user under FreeBSD gives you the Primary Group for the user you have requested. Supplemental groups are available only for that user, not the user you ran Zope as. Interesting. NetBSD has the Linux behaviour. The Apache CGI wrapper does setgid and initgroups, in that order. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] supplemental group ids (Linux)
Chris McDonough [EMAIL PROTECTED] wrote: Aplogies for the ignorance, but can you maybe explain the concept of supplemental group ids and give an example of how the current unpatched behavior could be subverted? I can try... Supplemental gids are useful for allowing a user to belong to more than one group, or maybe to more than one project in normal parlance. This is normally effected by listing the uid opposite more than one group in /etc/group. The login process issues the initgroups(3) call to install these supplemental groups, which are inherited by all processes forked from the login shell. The problem is comes when you change user ids; for example what I saw with Zope (start -u nobody) was: before change after change = user id root nobody group idroot nobody sup id(s) root root Thus the process has group access privilages for nobody (correct) and root (bad) in unpatched Zope. I cannot give you an exploit based on this -- my knowledge of Zope is not deep enough -- and in a bug free world there probably would be no exploit. But the reason for running as nobody, I think, is to contain damage should an exploit be found. For that reason, it would seem reasonable to change the supplemental gids too. I saw this on Linux; supplemental groups come from the BSD tradition, so you likely will find the same situation on *BSD, Solaris, etc. ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
