Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Guido van Rossum [EMAIL PROTECTED] wrote: OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it to death in abstracto. However, the ORIGINAL proposal in this thread (to split off argv[0] and/or make that and the arguments read-only) is entirely different. That is purely a matter of convenience, cleanliness of specification or whatever you call it. I can't imagine any good reason to separate argv[0] from argv[1:] by a sandbox (either way). Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/14/06, Nick Maclaren [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it to death in abstracto. However, the ORIGINAL proposal in this thread (to split off argv[0] and/or make that and the arguments read-only) is entirely different. That is purely a matter of convenience, cleanliness of specification or whatever you call it. I can't imagine any good reason to separate argv[0] from argv[1:] by a sandbox (either way). Sure. But that proposal has already been discussed (and found little opposition). The thread then dispersed in a much less focused discussion about the true purpose of the sys module.. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Greg Ewing [EMAIL PROTECTED] wrote: On systems that are not Unix-derived (which, nowadays, are rare), there is commonly no such thing as a program name in the first place. It is possible to get into that state on some Unices - i.e. ones which have a form of exec that takes a file descriptor, inode number or whatever. I don't think that applies to the Python args[] though, since its args[0] isn't the path of the OS-level executable, it's the path of the main Python script. Oh, yes, it does! The file descriptor or inode number could refer to the script just as well as it could to the interpreter binary. But you could still end up without one, if the main script comes from somewhere other than a file. I didn't want to include that, to avoid confusing people who haven't used systems with such features. Several systems have had the ability to exec to a memory segment, for example. But, yes. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Nick Maclaren wrote: I don't think that applies to the Python args[] though, since its args[0] isn't the path of the OS-level executable, it's the path of the main Python script. Oh, yes, it does! The file descriptor or inode number could refer to the script just as well as it could to the interpreter binary. (insert sound of head hitting desk here) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Greg Ewing wrote: Nick Maclaren wrote: On systems that are not Unix-derived (which, nowadays, are rare), there is commonly no such thing as a program name in the first place. It is possible to get into that state on some Unices - i.e. ones which have a form of exec that takes a file descriptor, inode number or whatever. I don't think that applies to the Python args[] though, since its args[0] isn't the path of the OS-level executable, it's the path of the main Python script. But you could still end up without one, if the main script comes from somewhere other than a file. sys.argv[0] can end up being None in Python 2.5 - zipimporter objects don't currently expose the info runpy.run_module needs to set __file__ and sys.argv[0] correctly, so they'll both end up being None if you use -m to run a module from a zipfile. PEP 302 went a fairly long way towards decoupling imports from the filesystem lay out, but it isn't all the way there just yet. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Greg Ewing wrote: Maybe sys needs to be split into two modules, with the non-sensitive one pre-imported (so that the importless interpreter you suggest wouldn't be unnecessarily crippled). Maybe not splitting it, but providing a read-only mechanism of getting at certain elements, with import sys still being the way of *modifying* any of these things. Relatively safe items (could be provided as attributes and methods of a read-only class instance in builtins instead of as a module): argv (as a tuple instead of a list) byteorder maxint maxunicode builtin_module_names copyright exc_info() exec_prefix executable exit([arg]) getdefaultencoding() getfilesystemencoding() getwindowsversion() hexversion platform prefix stdin stdout stderr version version_info winver Arguably privileged information (no real reason for non-privileged code to know this stuff): subversion getcheckinterval() getdlopenflags() dllhandle _current_frames() getrefcount(object) getrecursionlimit() _getframe([depth]) __displayhook__ __excepthook__ __stdin__ __stdout__ __stderr__ api_version warnoptions tracebacklimit displayhook(value) excepthook(type, value, traceback) ps1 ps2 Definitely privileged operations: Actually *setting* any of the above to something different modules path exc_clear() setcheckinterval(interval) setdefaultencoding(name) setdlopenflags(n) setprofile(profilefunc) setrecursionlimit(limit) settrace(tracefunc) settscdump(on_flag) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Whoa, whoa. What's the *problem* we're trying to solve here? On 7/14/06, Nick Coghlan [EMAIL PROTECTED] wrote: Greg Ewing wrote: Maybe sys needs to be split into two modules, with the non-sensitive one pre-imported (so that the importless interpreter you suggest wouldn't be unnecessarily crippled). Maybe not splitting it, but providing a read-only mechanism of getting at certain elements, with import sys still being the way of *modifying* any of these things. Relatively safe items (could be provided as attributes and methods of a read-only class instance in builtins instead of as a module): argv (as a tuple instead of a list) byteorder maxint maxunicode builtin_module_names copyright exc_info() exec_prefix executable exit([arg]) getdefaultencoding() getfilesystemencoding() getwindowsversion() hexversion platform prefix stdin stdout stderr version version_info winver Arguably privileged information (no real reason for non-privileged code to know this stuff): subversion getcheckinterval() getdlopenflags() dllhandle _current_frames() getrefcount(object) getrecursionlimit() _getframe([depth]) __displayhook__ __excepthook__ __stdin__ __stdout__ __stderr__ api_version warnoptions tracebacklimit displayhook(value) excepthook(type, value, traceback) ps1 ps2 Definitely privileged operations: Actually *setting* any of the above to something different modules path exc_clear() setcheckinterval(interval) setdefaultencoding(name) setdlopenflags(n) setprofile(profilefunc) setrecursionlimit(limit) settrace(tracefunc) settscdump(on_flag) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/14/06, Brett Cannon [EMAIL PROTECTED] wrote: On 7/14/06, Guido van Rossum [EMAIL PROTECTED] wrote: Whoa, whoa. What's the *problem* we're trying to solve here? I have a use case for sandboxing. I am already having to plan to have a mini-sys module in a sandbox so that they cannot get access to dangerous things. OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it to death in abstracto. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/14/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/14/06, Brett Cannon [EMAIL PROTECTED] wrote: On 7/14/06, Guido van Rossum [EMAIL PROTECTED] wrote: Whoa, whoa. What's the *problem* we're trying to solve here? I have a use case for sandboxing.I am already having to plan to have a mini-sys module in a sandbox so that they cannot get access to dangerous things.OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it todeath in abstracto.Fine by me. My design doc already has a preliminary list going that people can take a look at. But it could still change if security analysis shows possible problems with exposing some of them. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Handling of sys.args (Re: User's complaints)
Ka-Ping Yee wrote: Having to 'import sys' to get at the command-line arguments always seemed awkward to me. 'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged. Would it help if sys were pre-imported into the builtins? Or do you think that args shouldn't live in sys at all? Recently I've come to appreciate the ability to get at the args from anywhere, instead of having to catch them from a call to main() and pass them around. So I'd like to still be able to import them from somewhere if I want (doesn't have to be sys, though). And while we're on the subject, anyone think it would be a good idea to drop the silly feature of having the program name as args[0]? You almost *never* want to treat it the same way as the rest of the args, so the first thing you always do is args[1:]. It's not so bad in C, where it's just as easy to start indexing argv from 1 instead of 0. But it makes no sense in Python, IMO. It would be much more sensible to move it into a separate attribute of whatever module we decide to put args in. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/13/06, Greg Ewing [EMAIL PROTECTED] wrote: Ka-Ping Yee wrote: Having to 'import sys' to get at the command-line arguments always seemed awkward to me.'import sys' feels like it should be a privileged operation (access to interpreter internals), and getting the command-line args isn't privileged.Would it help if sys were pre-imported into the builtins?Or do you think that args shouldn't live in sys at all?Recently I've come to appreciate the ability to get at the args from anywhere, instead of having to catch themfrom a call to main() and pass them around. So I'dlike to still be able to import them from somewhereif I want (doesn't have to be sys, though). And while we're on the subject, anyone think it wouldbe a good idea to drop the silly feature of havingthe program name as args[0]? You almost *never* wantto treat it the same way as the rest of the args,so the first thing you always do is args[1:]. It's not so bad in C, where it's just as easy tostart indexing argv from 1 instead of 0. But itmakes no sense in Python, IMO. It would be muchmore sensible to move it into a separate attributeof whatever module we decide to put args in. Makes sense to me. Ruby does this and it makes working with arguments a little bit nicer.-Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On Thu, 13 Jul 2006, Greg Ewing wrote: Would it help if sys were pre-imported into the builtins? Or do you think that args shouldn't live in sys at all? I feel like the command-line arguments don't really belong in sys, and i'd rather not have 'sys' pre-imported into the builtins. I think of 'sys' as the place for sensitive interpreter internals and the builtins as the place for harmless functions. They're at opposite ends of the scale -- 'sys' is the most privileged; builtins are the least privileged. From a security point of view, 'import' is the main way to get dangerous new functionality. I realize 'open' breaks this concept, but it's nice to be able to say, to a rough approximation, that preventing 'import' gives you an interpreter that can do computations but isn't a security risk. These are just my feelings -- i'm not sure how consistent this is with the original intent of 'sys'. I think it would be a quite useful distinction to have, though. And while we're on the subject, anyone think it would be a good idea to drop the silly feature of having the program name as args[0]? You almost *never* want to treat it the same way as the rest of the args, so the first thing you always do is args[1:]. Starting the args array with the first argument (and putting the program name somewhere else) seems Pythonic to me. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/13/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: On Thu, 13 Jul 2006, Greg Ewing wrote: Would it help if sys were pre-imported into the builtins? Or do you think that args shouldn't live in sys at all? I feel like the command-line arguments don't really belong in sys, and i'd rather not have 'sys' pre-imported into the builtins. I think of 'sys' as the place for sensitive interpreter internals and the builtins as the place for harmless functions. They're at opposite ends of the scale -- 'sys' is the most privileged; builtins are the least privileged. From a security point of view, 'import' is the main way to get dangerous new functionality. I realize 'open' breaks this concept, but it's nice to be able to say, to a rough approximation, that preventing 'import' gives you an interpreter that can do computations but isn't a security risk. These are just my feelings -- i'm not sure how consistent this is with the original intent of 'sys'. I think it would be a quite useful distinction to have, though. sys is a grab-bag. Note that it also has a good deal of harmless read-only data: maxint, version, platform and many more. But it seems to specialize in things that you may modify to change global behavior: path, modules, stdout, ps1, displayhook and others. I'nm afraid if we were to split it by functionality we'd have to split it 5-way or so... And while we're on the subject, anyone think it would be a good idea to drop the silly feature of having the program name as args[0]? You almost *never* want to treat it the same way as the rest of the args, so the first thing you always do is args[1:]. Starting the args array with the first argument (and putting the program name somewhere else) seems Pythonic to me. As long as it's called args, not argv, I agree. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On systems that are not Unix-derived (which, nowadays, are rare), there is commonly no such thing as a program name in the first place. It is possible to get into that state on some Unices - i.e. ones which have a form of exec that takes a file descriptor, inode number or whatever. This is another argument for separating off argv[0] and allowing the program name to be None if there IS no program name. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Ka-Ping Yee wrote: I think of 'sys' as the place for sensitive interpreter internals Well, it seems to be rather a mixture at the moment. I suppose you could regard sys.modules as fairly sensitive, since messing with it can have big effects on the behaviour of the whole program, and changing sys.stdout or sys.stderr also has global effects. But it's also how you do things like getting info about the current exception, which doesn't seem particularly sensitive to me. Maybe sys needs to be split into two modules, with the non-sensitive one pre-imported (so that the importless interpreter you suggest wouldn't be unnecessarily crippled). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Guido van Rossum wrote: I'nm afraid if we were to split it by functionality we'd have to split it 5-way or so... What about just splitting it into mutable and immutable parts? That would be a fairly clear division, I think. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Nick Maclaren wrote: On systems that are not Unix-derived (which, nowadays, are rare), there is commonly no such thing as a program name in the first place. It is possible to get into that state on some Unices - i.e. ones which have a form of exec that takes a file descriptor, inode number or whatever. I don't think that applies to the Python args[] though, since its args[0] isn't the path of the OS-level executable, it's the path of the main Python script. But you could still end up without one, if the main script comes from somewhere other than a file. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
