[Zope] [PATCH] doesn't? Please fix... ;-)
Andrew Kenneth Milton <[EMAIL PROTECTED]> wrote:
>+-------[ Kip Rugger ]--
>|
>| [snip]
>|
>|
>| crap
>| more crap
>|
>| Lots of crap
>|
>|
>|
>| 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 arb stuff
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)
>OK, something is not quite right here.
>On my unmodified zope, it is properly 'sandboxed'. Perhaps it is the use of
>the explicit '-u nobody'? I don't do that on
>my system, which causes Zope to run as nobody implicitly.
>
>(When started as root, unless told otherwise, zope will switch to nobody).
>
>Try running without the 'u nobody switch, and see what happens. Just out of
>curiousity.
No difference.
I think the point is that Zope does not make any initgroups(3) calls;
this will be a problem if the particular system needs it.
I have two such systems:
Linux 2.2.16 + glibc-2.1.2
NetBSD 1.4
Having reviewed the kernel and libc sources in both cases, I am convinced
that set*gid and {init,set,get}groups operate totally independently.
At minimum, initgroups is used by login/su to set the primary gid found
in /etc/passwd, plus any additional gids associated with the uid in
/etc/group, as supplemental gids. Thus, even if there are no supplemental
gids in /etc/group, you still have the primary gid in the kernel's list
of supplementals. So the primary gid occurs initially in 3 places:
the real and effective gids, and one of the supplemental gids.
You must get all 3; setgid for real and eff, initgroups for sup.
(Additionally in linux you have the `saved' gid and the fsgid, but
setgid will modify them.)
Under this hypothesis, my question is how could _your_ system work?
Why is it that you don't have the original primary gid lingering in
the supplemental list?
___
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)
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)
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 )
[Zope] supplemental group ids (Linux)
I noticed when starting Zope as root (to get privilaged ports),
but requesting suid to `nobody' (start -u nobody) the resulting
processes have the correct uid and gid, but the supplemental
group id list still has the appropriate value for root. This
means that the Zope process could, for example, write to files
that may belong to root.
It's not clear whether this deserves a bug report, so I though
I'd ask here instead.
The fix is easy (and very lightly tested):
1) grab and install the supplemental gid package (for python)
http://www.ccraig.org/software/group.c
2) patch (for 2.2.0)
--- z2.py.orig Fri Jun 30 10:23:53 2000
+++ z2.py Mon Sep 4 14:33:51 2000
@@ -682,13 +682,20 @@
if type(UID) == type(""):
uid = pwd.getpwnam(UID)[2]
gid = pwd.getpwnam(UID)[3]
+uname = UID
elif type(UID) == type(1):
uid = pwd.getpwuid(UID)[2]
gid = pwd.getpwuid(UID)[3]
+uname = pwd.getpwuid(UID)[1]
else:
raise KeyError
try:
if gid is not None:
+try:
+import group
+group.initgroups(uname, gid)
+except:
+pass
try:
os.setgid(gid)
except OSError:
___
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] doesn't? Please fix... ;-)
In article <[EMAIL PROTECTED]>, Andrew Kenneth Milton <[EMAIL PROTECTED]> wrote: [snip] >It's wrong :-) > > >crap >more crap > >Lots of crap > > > >In order to parse that fragment, you need to parse the blocks in case you >find another opening block, so that you can recursively process comments. > [snip] crap more crap Lots of crap by analogy with the common practice of #if 0 in C ___ 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 )
