[ python-Bugs-1455641 ] pyport.h freebsd inconsistent
Bugs item #1455641, was opened at 2006-03-22 05:43 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Hye-Shik Chang (perky) Summary: pyport.h freebsd inconsistent Initial Comment: pyport.h redefines isalnum and friends #if __FreeBSD_version > 500039 but the comment just above says not to do so in FreeBSD 6 (which is now available). Add an extra guard clause? -- >Comment By: Hye-Shik Chang (perky) Date: 2006-03-22 17:55 Message: Logged In: YES user_id=55188 The workaround is still needed for FreeBSD 6 and 7 even. >>> import locale >>> locale.setlocale(locale.LC_ALL, 'de_DE.UTF-8') 'de_DE.UTF-8' >>> import ctypes >>> ctypes.cdll.c.isspace(0xa0) 1 This should be 0 to get a correct result from str.split. I fixed the comment in r43219. Thank you! -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-22 16:54 Message: Logged In: YES user_id=849994 perky, you added that comment to pyport.h. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1455641&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451503 ] os.startfile() still doesn't work with Unicode filenames
Bugs item #1451503, was opened at 2006-03-16 18:08 Message generated for change (Comment added) made by roee88 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roee88 (roee88) Assigned to: Nobody/Anonymous (nobody) Summary: os.startfile() still doesn't work with Unicode filenames Initial Comment: >From 2.4.2 changelog: >>>Bug #1007046: os.startfile() did not accept unicode strings encoded in the file system encoding. If the filename is unicode type and the encoding isn't the default system encoding, all "unknown" (to system encoding) characters are replaced by "?". This is causing the os.startfile() to fail with WindowsError: [Errno2] Because the filename doesn't really have the "?". -- >Comment By: roee88 (roee88) Date: 2006-03-22 12:00 Message: Logged In: YES user_id=143 Sorry, but I can't work on a patch. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-19 10:49 Message: Logged In: YES user_id=21627 Well, it does work on Unicode strings when all characters from the string come from the system code page; this got implemented in response to bug #1007046. To fix this, the implementation should use ShellExecuteW (except on Win9x). Would you like to work on a patch? As a work-around, change your system code page so your file names are supported. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451503&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Christoph Zwerschke (cito) Assigned to: Martin v. Löwis (loewis) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-22 14:56 Message: Logged In: YES user_id=21627 I've committed this patch (along with a test case) as 43227 into the 2.4 branch; the trunk still needs fixing. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 22:14 Message: Logged In: YES user_id=33168 Actually, I don't much care about the answer as long as it isn't a core dump/assert or a SystemError. I'm fine with a syntax error. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-20 10:03 Message: Logged In: YES user_id=21627 I still wonder why anybody would want to do that, so I don't see it as a big problem that it gives an error in 2.4: it *should* give an error, although not the one it currently gives. It seems that wigy would expect that the encoding declaration is ignored, whereas you (nnorwitz) are suggesting that the UTF-8 default should be ignored. In the face of ambiguity, refuse the temptation to guess. So I still think it should give a SyntaxError instead. I'll attach an alternative patch. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 09:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 22:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-28 07:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-28 06:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this erro
[ python-Bugs-1454912 ] import email fails
Bugs item #1454912, was opened at 2006-03-20 16:26 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Barry A. Warsaw (bwarsaw) Summary: import email fails Initial Comment: After Barry's merge of the email 4.0 package, importing email fails with the message that mime cannot be imported. The reason seems to be that email/mime should be added to LIBSUBDIRS in the top-level Makefile.pre.in. -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-22 09:58 Message: Logged In: YES user_id=12800 r43228 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1454912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436532 ] length of unicode string changes print behaviour
Bugs item #1436532, was opened at 2006-02-22 10:45 Message generated for change (Comment added) made by hover_boy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James (hover_boy) Assigned to: Kurt B. Kaiser (kbk) Summary: length of unicode string changes print behaviour Initial Comment: Python 2.4.2 and IDLE (with Courier New font) on XP and the following code saved as a UTF-8 file if __name__ == "__main__": print "é¶ ä¸ äº ä¸ å äº å ä¸ å «" print "é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å " results in... IDLE 1.1.2 >>> RESTART >>> éâºÂ¶ ä¸⬠亊ä¸Ⱐåâºâº äºâ Ã¥â¦Ã¤Â¸Æ Ã¥â¦Â« é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å >>> -- >Comment By: James (hover_boy) Date: 2006-03-22 16:12 Message: Logged In: YES user_id=1458491 -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 02:44 Message: Logged In: YES user_id=593130 I am fairly ignorant of unicode and encodings, but I am surprised you got anything coherent without an encoding cookie comment at the top (see manual). Have you tried that? Other questions that might help someone answer: What specific XP version? SP2 installed? Country version? Your results for >>> sys.getdefaultencoding() 'ascii' >>> sys.getfilesystemencoding() 'mbcs' What happens if you reverse the order of the print statements? (Ie, is it really the shorter string that does not work or just the first?) I don't know enough to know if this is really a bug. If you don't get an answer here, you might try for more info on python-list/comp.lang.python -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436532 ] length of unicode string changes print behaviour
Bugs item #1436532, was opened at 2006-02-22 10:45 Message generated for change (Comment added) made by hover_boy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James (hover_boy) Assigned to: Kurt B. Kaiser (kbk) Summary: length of unicode string changes print behaviour Initial Comment: Python 2.4.2 and IDLE (with Courier New font) on XP and the following code saved as a UTF-8 file if __name__ == "__main__": print "é¶ ä¸ äº ä¸ å äº å ä¸ å «" print "é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å " results in... IDLE 1.1.2 >>> RESTART >>> éâºÂ¶ ä¸⬠亊ä¸Ⱐåâºâº äºâ Ã¥â¦Ã¤Â¸Æ Ã¥â¦Â« é¶ ä¸ äº ä¸ å äº å ä¸ å « ä¹ å >>> -- >Comment By: James (hover_boy) Date: 2006-03-22 16:21 Message: Logged In: YES user_id=1458491 I've attached an example file to demonstrate the problem better. it seems not to be the length but something else which I haven't figured out yet. I've also added the encoding comment and also tried changing the default encoding in sitecustomize.py from latin -1 to utf-8 but neither seem to work. thanks, James. XP professional, SP2, english -- Comment By: James (hover_boy) Date: 2006-03-22 16:12 Message: Logged In: YES user_id=1458491 -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-06 02:44 Message: Logged In: YES user_id=593130 I am fairly ignorant of unicode and encodings, but I am surprised you got anything coherent without an encoding cookie comment at the top (see manual). Have you tried that? Other questions that might help someone answer: What specific XP version? SP2 installed? Country version? Your results for >>> sys.getdefaultencoding() 'ascii' >>> sys.getfilesystemencoding() 'mbcs' What happens if you reverse the order of the print statements? (Ie, is it really the shorter string that does not work or just the first?) I don't know enough to know if this is really a bug. If you don't get an answer here, you might try for more info on python-list/comp.lang.python -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Bugs item #1456209, was opened at 2006-03-22 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456209 ] dictobject.c:dictresize() vulnerability
Bugs item #1456209, was opened at 2006-03-22 15:47 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: dictobject.c:dictresize() vulnerability Initial Comment: We thought we squashed the last of the modify-the-dict-from-a-custom-eq kind of bugs long ago. Too bad. -- >Comment By: Armin Rigo (arigo) Date: 2006-03-22 16:32 Message: Logged In: YES user_id=4771 The cause of the bug is that if oldtable == mp->ma_smalltable then pure Python code can mangle with mp->ma_smalltable while it is being walked on. A simple fix would be to always make a copy of the oldtable if it is mp->ma_smalltable (not only if oldtable == newtable). Attached a more efficient fix, which should also make dict resizing somehow faster. It requires yet another version of the lookup algorithm, though. It's a very simple version that assumes that all items are different and the dict contains no dummy entries. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456209&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456280 ] Traceback error when compiling Regex
Bugs item #1456280, was opened at 2006-03-22 18:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wolfgang Grafen (grafen)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Traceback error when compiling Regex
Initial Comment:
Traceback error when compiling the following regular
expression. Error discovered with Python 2.4.2.
Used pre from python2.3 to check the validity of
re_fmt. With pre it works fine.
Question:
I submitted a sre error report before and I warned
to take off pre from the library. It is of advantage
to be able to check a failing re with pre. Personally
I feel sre has still too many bugs to completely
substitute pre.
Regards
Wolfgang Grafen
==
chios scalar 582 % ./fmtscalar.py
Traceback (most recent call last):
File "./fmtscalar.py", line 21, in ?
re_fmt = re.compile(
File "/user/freepool/local/lib/python2.3/sre.py",
line 179, in compile
return _compile(pattern, flags)
File "/user/freepool/local/lib/python2.3/sre.py",
line 230, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
cut here
#!/usr/bin/env python2.3
# -*- coding: Latin-1 -*-
import sre as re
re_fmt = re.compile(
"("
"%"
"(?P"
"\d+"
"(?:"
"[.]"
"\d+"
")"
")?"
"(?:"
"[(]"
"(?P"
"[^)]*"
")?"
"[)]"
")?"
"(?P[a-z])"
")"
)
a="%s"
b="aber%sxyz"
c="aber%3.1i"
c="aber%(quengel)s"
for i in a,b,c:
m = re_fmt.findall(i)
print i,m
cut here ---
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456280&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284316 ] Win32: Security problem with default installation directory
Bugs item #1284316, was opened at 2005-09-07 23:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Mika Eloranta (mel) Assigned to: Martin v. Löwis (loewis) Summary: Win32: Security problem with default installation directory Initial Comment: (Sorry, this is a bit long since the issue is not entirely trivial.) This problem only exists on Windows operating systems installed on an NTFS file system. Confirmed on several Windows 2000, XP and Windows 2003 Server systems. All Python versions (at least 2.x) are affected. The default installation target directory where Python is installation on Windows is directly under the system drive's root directory (e.g. "C:\python24"). The file and directory permissions inherited by the python24-directory from the root directory are not secure enough for keeping application binaries. Microsoft has, in their infinite wisdom, decided that the root directory of the system drive should allow regular (non-admin) users to create directories and files there. This set of permissions is inherited by the python directory when it is created in the default location (i.e. "C:\python24" or whatever). This "feature" allows a regular (non-admin) user to perform a priviledge escalation attack for example in the following manner: 1. Figure out the name of some DLL python (or some extension .PYD) loads using LoadLibrary() without an absolute path. 2. Copy a DLL with the same name into the python-directory (this should not be allowed, but it is!) containing some code the attacker wants to run with escalated priviledges. 3. Wait until python is run by an admin in the same machine or by the LocalSystem account. How to view the problematic part of the ACL: 1. Right-click the "C:\python24" directory in Windows Explorer 2. select Properties... -> Security -> Advanced 3. In the "Permissions" tab you will see an entry for the "Users" group, it says "Special" in the "Permissions" column 4. Select the above entry and click "Edit..." 5. Well hidden? I think so, too. The fix: The proper (default) location where application binaries should be installed is under the "c:\program files\" directory. This directory has properly set permissions by default. PS. The same problem exists in ActivePerl, Ruby and many other tools. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-03-22 20:09 Message: Logged In: YES user_id=21627 I completely disagree. It was wrong to give the system default binary directory a name with a space in it, on a system that doesn't provide command line argument vectors in its standard API. -- Comment By: Mika Eloranta (mel) Date: 2005-11-19 09:46 Message: Logged In: YES user_id=109057 Wow, even easy_install.exe from setuptools fails if python is installed under "c:\program files": C:\temp>easy_install C:\program: can't open file 'files\Python24\python.exe': [Errno 2] No such file or directory IMHO the root cause to all these problems is the wrong default installation directory. If the installation directory would conform to Windows guidelines, these kind of problems would have been easily spotted by python library developers. - Mika -- Comment By: Mika Eloranta (mel) Date: 2005-11-15 12:39 Message: Logged In: YES user_id=109057 Please consider these points as well: * The "program files" directory has "sensible" ACLs set by default (the defaults are different in different OS versions). If you install your application under "program files", you do not need to worry about the permissions. * The installation directory can be added to the PATH environment variable instead of typing it every time from console... * The current default installation directory is teaching python library developers bad habits of not handling Python installed into a directory that contains spaces properly. It is actually a miracle to find a third party library that installs a working script (batch file) to "python/scripts" if the python directory contains spaces. * The "program files" directory is the standard location where applications should be installed in Windows. This is what Microsoft requires in their guidelines and most applications obey them. You would not install python to "/python24" by default in Unix would you? -- Comment By: Martin v. Löwis (loewis) Date: 2005-10-08 11:48 Message: Logged In: YES user_id
[ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Bugs item #1448058, was opened at 2006-03-12 02:19 Message generated for change (Comment added) made by aix-d You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: aix-d (aix-d) Assigned to: Nobody/Anonymous (nobody) Summary: problems with too many sockets in FreeBSD Initial Comment: When there are about 200 sockets, or so, i'm getting errors: "unable to select on socket" We are running multithread application, for each thread there is one socket. TRACEBACK contains: r = self.connection.recv(1024) error: unable to select on socket. This error appeared after fixing this problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470 Python version: 2.5a0 (trunk, Mar 8 2006, 18:28:30) OS version: FreeBSD 6.1-PRERELEASE Soon we will make program that will reproduce this error if needed. -- >Comment By: aix-d (aix-d) Date: 2006-03-22 22:32 Message: Logged In: YES user_id=1449422 Thank you very much! It was fixed by increasing FD_SETSIZE. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-14 10:37 Message: Logged In: YES user_id=33168 What is the value of FD_SETSIZE? Perhaps you should increase this value before including any headers on FreeBSD? If you are using a lot of sockets, you may prefer to use poll() instead of select() as poll() doesn't have the FD_SETSIZE limitation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284316 ] Win32: Security problem with default installation directory
Bugs item #1284316, was opened at 2005-09-07 17:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Platform-specific Status: Open Resolution: None Priority: 7 Submitted By: Mika Eloranta (mel) Assigned to: Martin v. Löwis (loewis) Summary: Win32: Security problem with default installation directory Initial Comment: (Sorry, this is a bit long since the issue is not entirely trivial.) This problem only exists on Windows operating systems installed on an NTFS file system. Confirmed on several Windows 2000, XP and Windows 2003 Server systems. All Python versions (at least 2.x) are affected. The default installation target directory where Python is installation on Windows is directly under the system drive's root directory (e.g. "C:\python24"). The file and directory permissions inherited by the python24-directory from the root directory are not secure enough for keeping application binaries. Microsoft has, in their infinite wisdom, decided that the root directory of the system drive should allow regular (non-admin) users to create directories and files there. This set of permissions is inherited by the python directory when it is created in the default location (i.e. "C:\python24" or whatever). This "feature" allows a regular (non-admin) user to perform a priviledge escalation attack for example in the following manner: 1. Figure out the name of some DLL python (or some extension .PYD) loads using LoadLibrary() without an absolute path. 2. Copy a DLL with the same name into the python-directory (this should not be allowed, but it is!) containing some code the attacker wants to run with escalated priviledges. 3. Wait until python is run by an admin in the same machine or by the LocalSystem account. How to view the problematic part of the ACL: 1. Right-click the "C:\python24" directory in Windows Explorer 2. select Properties... -> Security -> Advanced 3. In the "Permissions" tab you will see an entry for the "Users" group, it says "Special" in the "Permissions" column 4. Select the above entry and click "Edit..." 5. Well hidden? I think so, too. The fix: The proper (default) location where application binaries should be installed is under the "c:\program files\" directory. This directory has properly set permissions by default. PS. The same problem exists in ActivePerl, Ruby and many other tools. -- >Comment By: Tim Peters (tim_one) Date: 2006-03-22 15:27 Message: Logged In: YES user_id=31435 A long time ago, Python did install (by default) under "Program Files". I changed that, because of the endless problems created by the frickin' embedded space, and rarer but subtler problems due to "Program Files" not being a DOSish 8.3 name. Overall I still think it was a good change. Note that, unlike most Windows applications (which are GUI-based), programming languages are _intended_ to be used heavily from the command line, invoked by scripts, and so on. That's what makes a space in the path endlessly error-prone. In WinXP Pro, I noticed that MS was still careful to put its own command-line/script tools (sort.exe, ipconfig.exe, cscript.exe, ..., even notepad.exe) under pure DOSish 8.3 space-free paths ;-) -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-22 14:09 Message: Logged In: YES user_id=21627 I completely disagree. It was wrong to give the system default binary directory a name with a space in it, on a system that doesn't provide command line argument vectors in its standard API. -- Comment By: Mika Eloranta (mel) Date: 2005-11-19 03:46 Message: Logged In: YES user_id=109057 Wow, even easy_install.exe from setuptools fails if python is installed under "c:\program files": C:\temp>easy_install C:\program: can't open file 'files\Python24\python.exe': [Errno 2] No such file or directory IMHO the root cause to all these problems is the wrong default installation directory. If the installation directory would conform to Windows guidelines, these kind of problems would have been easily spotted by python library developers. - Mika -- Comment By: Mika Eloranta (mel) Date: 2005-11-15 06:39 Message: Logged In: YES user_id=109057 Please consider these points as well: * The "program files" directory has "sensible" ACLs set by default (the defaults are different in different OS versions). If you install your application under "program files", you do not need to worry about the permissions.
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 05:11 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Christoph Zwerschke (cito) >Assigned to: Neal Norwitz (nnorwitz) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-22 05:56 Message: Logged In: YES user_id=21627 I've committed this patch (along with a test case) as 43227 into the 2.4 branch; the trunk still needs fixing. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 13:14 Message: Logged In: YES user_id=33168 Actually, I don't much care about the answer as long as it isn't a core dump/assert or a SystemError. I'm fine with a syntax error. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-20 01:03 Message: Logged In: YES user_id=21627 I still wonder why anybody would want to do that, so I don't see it as a big problem that it gives an error in 2.4: it *should* give an error, although not the one it currently gives. It seems that wigy would expect that the encoding declaration is ignored, whereas you (nnorwitz) are suggesting that the UTF-8 default should be ignored. In the face of ambiguity, refuse the temptation to guess. So I still think it should give a SyntaxError instead. I'll attach an alternative patch. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 13:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this e
[ python-Bugs-1456470 ] sliceobject ssize_t (and index) not completed
Bugs item #1456470, was opened at 2006-03-22 17:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: sliceobject ssize_t (and index) not completed Initial Comment: sliceobject and ceval changed the parameter types of slice objects to ssize_t, but the code still requires an int (sometimes not even a long); it should use the new __index__ slot; at the very least, it should be consistent about what it does accept. In http://svn.python.org/view/python/trunk/Objects/ sliceobject.c?rev=42382&view=markup [issue 1] function PySlice_GetIndices takes Py_ssize_t parameters for (length, start, stop, step) but then does a PyInt_Check on each of start, stop, step. (An XXX to allow longs was also removed.) It * should* use the new __index__ slot. [issue 2] Later in the same file, function slice_ indices takes a PyObject len parameter, but then uses PyInt_AsLong rather than __index__ (or even PyInt_ AsSsize_t) to create Py_ssize_t ilen. [issue 3] http://svn.python.org/view/python/trunk/Python/ceval.c? rev=42382&view=markup function _PyEval_SliceIndex accepts only ints and longs, and longs will be converted to ints with clipping. It should allow anything with __index__, and clip only to ssize_t rather than int. [issue 4] ISINT still insists on int or long -- I thought I saw a fix for this already in the index patches. [issue 5] apply_slice and assign_slice changed the types of ilow and ihigh, but still initializes them to INT_MAX rather than ssize_t max. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456470&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1448058 ] problems with too many sockets in FreeBSD
Bugs item #1448058, was opened at 2006-03-11 15:19 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: aix-d (aix-d) Assigned to: Nobody/Anonymous (nobody) Summary: problems with too many sockets in FreeBSD Initial Comment: When there are about 200 sockets, or so, i'm getting errors: "unable to select on socket" We are running multithread application, for each thread there is one socket. TRACEBACK contains: r = self.connection.recv(1024) error: unable to select on socket. This error appeared after fixing this problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1429585&group_id=5470&atid=105470 Python version: 2.5a0 (trunk, Mar 8 2006, 18:28:30) OS version: FreeBSD 6.1-PRERELEASE Soon we will make program that will reproduce this error if needed. -- Comment By: aix-d (aix-d) Date: 2006-03-22 11:32 Message: Logged In: YES user_id=1449422 Thank you very much! It was fixed by increasing FD_SETSIZE. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-13 23:37 Message: Logged In: YES user_id=33168 What is the value of FD_SETSIZE? Perhaps you should increase this value before including any headers on FreeBSD? If you are using a lot of sockets, you may prefer to use poll() instead of select() as poll() doesn't have the FD_SETSIZE limitation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448058&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1456609 ] PEP Links broken on new website
Bugs item #1456609, was opened at 2006-03-22 19:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: PEP Links broken on new website Initial Comment: The links genereated are in the form: http://www.python.org/dev/peps/pep-0340/pep-0288.html when they should be: http://www.python.org/dev/peps/pep-0288/ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1456609&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1444893 ] Pointer freed twice in Py_InitializeEx()
Bugs item #1444893, was opened at 03/07/06 06:39 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: athorp (athorp) Assigned to: Nobody/Anonymous (nobody) Summary: Pointer freed twice in Py_InitializeEx() Initial Comment: saved_locale is freed twice in pythonrun.c:Py_InitializeEx(). Example code attached. -- >Comment By: SourceForge Robot (sf-robot) Date: 03/22/06 19:24 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Neal Norwitz (nnorwitz) Date: 03/08/06 00:19 Message: Logged In: YES user_id=33168 Also, what system are you running on? Mine amd64 is Linux. -- Comment By: Neal Norwitz (nnorwitz) Date: 03/08/06 00:16 Message: Logged In: YES user_id=33168 I don't see a problem with the code in SVN (either head or 2.4 branch). When I run 2.5 (HEAD) code with your test (but not debug malloc) under valgrind on amd64, it doesn't report any problems. Can you review the code in SVN to see if you think this is still a problem. If so, can you provide a patch that you believe fixes this problem? -- Comment By: Georg Brandl (gbrandl) Date: 03/08/06 00:14 Message: Logged In: YES user_id=849994 Your example is not very instructive. It only segfaults on my box. Can you tell where exactly the problem is, and how you would solve it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1444893&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1115379 ] Built-in compile function with PEP 0263 encoding bug
Bugs item #1115379, was opened at 2005-02-03 05:11 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Christoph Zwerschke (cito) Assigned to: Neal Norwitz (nnorwitz) Summary: Built-in compile function with PEP 0263 encoding bug Initial Comment: a = 'print "Hello, World"' u = '# -*- coding: utf-8 -*-\n' + a print compile(a, '', 'exec') # ok print compile(u, '', 'exec') # ok print compile(unicode(a), '', 'exec') # ok print compile(unicode(u), '', 'exec') # error # The last line gives a SystemError. # Think this is a bug. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-22 21:40 Message: Logged In: YES user_id=33168 Updated PEP. Committed revision 43243. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-22 05:56 Message: Logged In: YES user_id=21627 I've committed this patch (along with a test case) as 43227 into the 2.4 branch; the trunk still needs fixing. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 13:14 Message: Logged In: YES user_id=33168 Actually, I don't much care about the answer as long as it isn't a core dump/assert or a SystemError. I'm fine with a syntax error. -- Comment By: Martin v. Löwis (loewis) Date: 2006-03-20 01:03 Message: Logged In: YES user_id=21627 I still wonder why anybody would want to do that, so I don't see it as a big problem that it gives an error in 2.4: it *should* give an error, although not the one it currently gives. It seems that wigy would expect that the encoding declaration is ignored, whereas you (nnorwitz) are suggesting that the UTF-8 default should be ignored. In the face of ambiguity, refuse the temptation to guess. So I still think it should give a SyntaxError instead. I'll attach an alternative patch. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 00:28 Message: Logged In: YES user_id=33168 Martin, the attached patches (2.4 and 2.5) fix the problem. However, it seems that the patches would violate the PEP according to one of your notes. I'm not sure about all the details, but ISTM based on your comment that if (flags && flags->cf_flags & PyCF_SOURCE_IS_UTF8) and (TYPE(n) == encoding_decl) this is an error that should be returned? I would like to get this fixed for 2.4.3, so we need to move fast for it. 2.5 can wait and is trivial to fix once we know what this is supposed to do. -- Comment By: Georg Brandl (gbrandl) Date: 2006-02-20 13:37 Message: Logged In: YES user_id=849994 This even aborts the interpreter in 2.5 HEAD with a failing assertion. -- Comment By: Martin v. Löwis (loewis) Date: 2005-09-27 22:48 Message: Logged In: YES user_id=21627 If you load the files manually, why is it that you want to decode them to Unicode before compile()ing them? Couldn't you just pass the bytes you read from the file to compile()? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:29 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the beginning of the file before I can give it to the compile() function. What special advantage comes from the fact that the compiler does not simply ignore encoding declaration nodes from unicode objects? Does this error message catch some possible errors or does it make the compiler code simpler? -- Comment By: Vágvölgyi Attila (wigy) Date: 2005-09-27 21:20 Message: Logged In: YES user_id=156682 If this special case is a feature, not a bug, than it breaks some symmetry for sure. If I run a script having utf-8 encoding from a file with python script.py then it has to have an encoding declaration. Now if I would like to load the same file manually, decode it to a unicode object, I also have to remove the encoding declaration at the
