[issue15795] Zipfile.extractall does not preserve file permissions

[Éric Araujo]

Éric Araujo  added the comment:

On second thought, maybe no fix should be backported.
Changing behaviour silently might break things, changing with a new option puts 
the change in a grey fix/enhancement area, so maybe better to let current 
versions as they are, with the bug/limitation noted in the documentation, and 
give control in 3.11 only.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Sam Ezeh]

Sam Ezeh  added the comment:

I don't know what the best course of action would be but if preserving 
permissions needs to be back-ported, could the default permission preservation 
flag in 3.11+ be the one to preserve safe permissions and then make it so that 
the previous versions (<3.11, without the constants) always take this course of 
action? Maintaining the different options for preserving permissions while 
still allowing for this functionality to be back-ported.

I don't have a strong opinion on backporting permission preservation but to me, 
it seems like it would be a change in behaviour instead of a bug fix. The 
current default in the PR is to not preserve any permissions but if necessary, 
I'll change it to whatever is agreed upon.

I'll move the constants into an enum, but right now I'm not sure how I'd name 
the class.

As an aside, while writing this comment I realised that the reason tests aren't 
passing on my end might very well be due to the fact I do CPython work on an 
NTFS partition instead of on my main EXT4 partition.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Éric Araujo]

Change by Éric Araujo :


--
versions: +Python 3.11 -Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Éric Araujo]

Éric Araujo  added the comment:

The new PR uses new constants*, so could not be backported as is (see my 
previous message).


(*side question: should the constants use an enum?)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Sam Ezeh]

Change by Sam Ezeh :


--
pull_requests: +30350
pull_request: https://github.com/python/cpython/pull/32289

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Sam Ezeh]

Change by Sam Ezeh :


--
nosy: +sam_ezeh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Selim Belhaouane]

Change by Selim Belhaouane :


--
nosy: +selimb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:

I left a review on the PR requesting for some tests, if it makes sense.

--
nosy: +nanjekyejoannah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Éric Araujo]

Éric Araujo  added the comment:

The pull request needs unit tests added to validate the changes.

Note that the patch attached here was a new feature, adding constants and 
parameters to control the behaviour, but the PR simply checks and applies 
permissions bits stored in the entry.  That seems correct and nice to me, and 
arguably a bugfix that should be backported, but more active core devs and/or 
zipfile experts should weigh in.

--
nosy: +eric.araujo
versions: +Python 3.10 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[William Woodruff]

Change by William Woodruff :


--
nosy: +yossarian

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Nikolay]

Nikolay  added the comment:

Is there any chance that the pull request will be accepted? I'm a bit tired of 
using workaround every time I need unzip something on linux.

--
nosy: +kulakov-n

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +17223
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17790

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[ABR]

Change by ABR :


--
nosy:  -arobert

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Étienne Dupuis]

Étienne Dupuis  added the comment:

A workaround is provided here: 
https://stackoverflow.com/questions/39296101/python-zipfile-removes-execute-permissions-from-binaries

--
nosy: +Étienne Dupuis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Christian Heimes]

Christian Heimes added the comment:

I like the partial opener trick. Can we have the examples in the public 
documentation of open(), too?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[STINNER Victor]

STINNER Victor added the comment:

> @haypo, suppose, one thread wants file with permissions A, and other thread 
> wants permissions B. If they will "set" them through umask(), race condition 
> may occur.

Ok, let's say thta you want file "x" with permission A=0o777 and file "y" with 
permission B=0b700.

You start with os.umask(0o077), as suggested by Christian.

>>> import os
>>> os.umask(0o077)
2
>>> x=open("x", "w")
>>> y=open("y", "w")
>>> os.system("ls -l x y")
-rw---. 1 haypo haypo 0 11 janv. 08:48 x
-rw---. 1 haypo haypo 0 11 janv. 08:48 y
0
>>> os.fchmod(x.fileno(), 0o777)
>>> os.system("ls -l x y")
-rwxrwxrwx. 1 haypo haypo 0 11 janv. 08:48 x
-rw---. 1 haypo haypo 0 11 janv. 08:48 y
0

This is a time window where the file "x" has the permission -rw--- instead 
of the expected -rwxrwxrwx. Ok, it's expected. But it's not an easy since 
initial permissions are are more strict that expected permisions.

The race condition only occurs if you work the other way, start with 
os.umask(0777) (default umask) and then change permissions of the file "x" to 
stricter. In this specific case, you *already* have two ways to do that in 
Python 3 (no change needed):

  fp = open("x", opener=partial(os.open, mode=0o700))
or:
  fd = os.open("x", os.O_WRONLY | os.O_CREAT, 0o700)
  fp = open(fd, "wb")

--

About documenting the default mode: the problem is that I'm not sure that *all* 
functions in Python, especially when using third party libraries, use the same 
default mode. Morever, the mode on Windows has a very different meaning. 
Permission per group is handled by ACLs, not with the integer "mode":
https://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx

On Windows, pmode of _open() only contains read and write permissions of the 
file, for everyone.

For all these reasons, I close the issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If you needs non-default permission for particular file, you can use one of 
available ways mentioned above.

I think this issue can be closed. The original issues are resolved:

1. os.open() (corresponding to syscall open()) allows this.
2. There are other ways to create Python file with specific permissions (pass 
fd or use opener).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

@haypo, suppose, one thread wants file with permissions A, and other thread 
wants permissions B. If they will "set" them through umask(), race condition 
may occur.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Christian Heimes]

Christian Heimes added the comment:

Victor, you are correct. That was exactly my point.

The most secure way is to tighten security and set umask to 0o077. It's 
basically a white list or locked down approach. With umask 0o077 all subsequent 
files, directories and other resources will be created without any permission 
for group and others. This is even true for operations that create a Unix 
socket.

You have to change the permission of files to a more permissive mode 
explicitly. Any mistake is easy to spot (access denied) and not catastrophic.

By the way fchmod() isn't necessarily the optimal way to change permission by 
file descriptor. The behavior of fchmod() isn't well defined for socket files. 
On Linux fchmod() of a Unix socket file does not alter the permission bits of 
the socket device file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[STINNER Victor]

STINNER Victor added the comment:

I don't understand the problem with umask(). It's standard and affect all
code even C extension calling directly or indirectly open(). It is more
secure to use umask() than setting mode on a few Python open() calls no?

For example, Python creates .pyc files. You cannot (easily) modify the
open() call to set mode, whereas it is affected by umask().

If you call umask() at startup, it affects all threads, there is no race
condition like open()+fchmod().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Brett Cannon]

Brett Cannon added the comment:

The point Serhiy is trying to make is that not everyone needs or cares about 
setting specific file permissions. Python's built-in open() function has not 
supported this for 26 years and so there's obviously not that much of a need if 
this has not consistently come up as a shortcoming.

Two, you say to "just pass" something like "0o644" as the mode. OK, but what 
does that even mean? As a Linux user you may know thanks to chmod usage, but a 
Windows user or someone who doesn't use a Linux shell won't have any idea what 
that octal constant represents. So how do you propose to help people set the 
proper mode? If you say "use os.O_CREAT" then you just made open() have 
functionality depend on the os module which no other built-in directly does for 
their API.

In other words you might call this simple, but I call it an advanced feature 
that's supported by os.fdopen(os.open()) already. So when I say a "clear 
design" I mean addressing the fact that it's non-obvious for beginners on how 
to use and something not everyone needs.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29214>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

Such construction is not so easy. Especially for beginners. Not everyone even 
uses context managers to work with files. They will try to use os.chmod(). More 
clever will use os.fchmod(fileobj.fileno()). And in rare case someone asks 
about race condition between threads. So, not implementing that is error prone, 
and also forces users to make hidden bugs.

Why not to follow the principle of Least Surprise ?

In you way, we did not have to implement a lot of things, that we have now. 
Like tempfile, shutil and so on. They may be implemented using complex 
combination of simplier items. Answer: these things make Python easy, secure 
and (insert good words here by yourself).

Why are you afraid to add one very simple thing ?

Next, what if I want to use, say, 'r+b', in that case I should remember 
combination of O_X constants like O_TRUNC|O_CREAT|O_APPEND and so on.. It's 
great that Python allows such things! really great! but how many people want to 
write that in their code?

(Sorry for long text, but I really can not understand)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

open(..., opener=partial(os.open, mode=0o644))

Not every combination of functions deserves a new parameter of a builtin.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

so, io.open() should just pass that value down to implementation. 
implementation should use this value instead of hard-coded 0o666.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

I expect this:

open(, perms=0o644)

Why not?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Brett Cannon]

Brett Cannon added the comment:

I agree with Serhiy that I don't think this is necessary for io.open() when 
os.open() supports this. But this really can't be discussed further until 
someone provides a clear design proposal on how to make this work with 
io.open().

--
nosy: +brett.cannon
type: behavior -> enhancement
versions:  -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

Permissions -- are very important thing. As I think, such high-level functions 
should not hide that important functionality from end-users.

Also, it is not difficult to make a patch (as I think).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

io.open() is high-level function. It handles buffering, encoding, newline 
translating. It is even higher-level than C's fopen().

Syscall open() is low-level. Python os.open() is an interface to this low-level 
feature.

There is a connection between low and high level -- io.open() accepts a file 
descriptor returned by os.open(). You also can provide the opener argument.

I don't think io.open() needs the support of mode and dir_fd arguments and all 
possible O_* flags. They are low-level features.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Марк Коренберг added the comment:

1. Yes, I'm reporting problem about standard open(), not os.open().
2. Yes, I know about umask. But unfortunatelly, umask affects whole process, 
including all threads, so it is not possible to force specific permissions 
without of race conditions with other threds.
3. Calling C's `open()` with `0666` MUST be documented (with mentioning of 
umask, which also affects these bits). This is `MUST` because `man 2 open` says 
that there is no default for `mode` argument, and it must be specified when 
O_CREAT / O_TMPFILE is specified.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Christian Heimes]

Christian Heimes added the comment:

I would be nice to have a public API to set permissions of files for io.open(), 
too.

Note to your note: the actual permission is influenced by the process' global 
umask. If you are concerned about security, you should set the umask to 0o077 
early.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[STINNER Victor]

STINNER Victor added the comment:

You can actually specify permission:

fd = os.open("document.txt", os.O_WRONLY | os.O_CREAT, 0o777)
fp = open(fd, "wb")
with fp:
   ...

You can also use the dir_fd parameter for even better security ;-)

Is your request for the standard open() function, rather than os.open()?

Note: io.FileIO(), the underlying object when calling the Python open(), calls 
the C open() function with 0o666 for the permission mode.

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Changes by Марк Коренберг :


--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

Changes by Марк Коренберг :


--
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29214] Standard open() does not allow to specify file permissions.

[Марк Коренберг]

New submission from Марк Коренберг:

1. Syscall open() allows that.
2. This is important to prevent race-conditions between creating a file with 
default permissions and calling fchmod().

--
components: Library (Lib)
messages: 285044
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Standard open() does not allow to specify file permissions.
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29214>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Karen Tracey]

Karen Tracey added the comment:

Note the zipfile being processed may have been created on a non-Unix system, 
and the external_attr value can't be usefully interpreted as permission bits 
when the value at _CD_CREATE_SYSTEM 
(https://hg.python.org/cpython/file/default/Lib/zipfile.py#l107) in the central 
directory entry is not Unix (3). Patches so far don't seem to guard against 
mistakenly assuming a foreign-system external_attr value can be interpreted as 
Unix permission bits.

(At present github is delivering zipfiles of repos with a create system value 
of 0 and external_attr values of 0.)

--
nosy: +kmtracey

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Mark Mikofski]

Mark Mikofski added the comment:

same problem in 2.7.5 on Oracle Linux 7.2

--
nosy: +bwanamarko

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
stage: commit review - needs patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Alexey Boriskin]

Alexey Boriskin added the comment:

I'm working on updating the patch to unify tarfile and zipfile interfaces and 
to restore owner/timestamp for zipfile

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Alexander Belopolsky]

Changes by Alexander Belopolsky alexander.belopol...@gmail.com:


--
nosy: +belopolsky

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[ABR]

ABR added the comment:

I hope this can be finally gotten in for 3.5, even if it's not the perfect 
solution.  I hit this issue and needed to call out to a subprocess as a 
work-around, but that's far less reliable.

--
nosy: +arobert

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
stage: patch review - commit review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

asyncio: setting file permissions of a Unix socket?

[Martin]

Hi! :)

I'm using the asyncio.Protocol interface to build a server which binds
to a unix socket file.  I want other system users to connect to the
unix socket, so to communicate with the server.

Where should I set the permissions of the file?

The problem is that the socket file is created when the programs
starts listening for the connections.  Because of this, I can't change
the file permission before a connection is made.  At the same time, a
connection can't happen because of the file permissions.

Currently, I workaround this with os.umask(0o000).  But I also want to
make other files later with default permissions.  So I have to revert
the umask, but where?  I can only do this in the client connection
code, which is out of place.

Bellow is what I've done.  Can you suggest a better way?  I wish to
avoid permission fixing code like os.umask() for every connection.
Maybe I shouldn't use asyncio.Protocol in the first place?

Thank you! :)

Example code:

#! /usr/bin/env python3

import os
import asyncio

class ExampleServer(asyncio.Protocol):
def __init__(self):
os.umask(0o002)# This is my workaround.  Can I avoid this?
# if not umask_restored: # An alternative workaround.
# os.umask(0o002)

def connection_made(self, transport):
self.transport = transport

def data_received(self, data):
print(Data: , data)
self.transport.write(bOK, bye!\n)
self.transport.close()


def main():
socket_filepath = /tmp/example-server.socket
loop = asyncio.get_event_loop()
server_coroutine = loop.create_unix_server(ExampleServer, socket_filepath)
server = loop.run_until_complete(server_coroutine)

os.umask(0o000) # This is my workaround.

try:
loop.run_forever()
except KeyboardInterrupt:
print(exit)
finally:
server.close()
loop.close()
os.remove(socket_filepath)


if __name__ == __main__:
main()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: asyncio: setting file permissions of a Unix socket?

[Michael Ströder]

Martin wrote:
 I'm using the asyncio.Protocol interface to build a server which binds
 to a unix socket file.  I want other system users to connect to the
 unix socket, so to communicate with the server.
 
 Where should I set the permissions of the file?

You should start the demon with a strict umask and set the permissions after
the socket is created.

Deriving from SocketServer.UnixStreamServer I'm overriding the server_bind()
method:

class MyServer(SocketServer.UnixStreamServer):
[..]
  def server_bind(self):
Override server_bind to set socket options.
self.socket.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
self.socket.settimeout(SOCKET_TIMEOUT)
try:
  os.unlink(self.server_address)
except OSError:
  if os.path.exists(self.server_address):
raise
SocketServer.UnixStreamServer.server_bind(self)
os.chmod(self.server_address,int(SOCKET_PERMISSIONS,8))
return # server_bind()

Ciao, Michael.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue15795] Zipfile.extractall does not preserve file permissions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The TarFile.extract() method has the set_attrs parameter which controls similar 
behavior but is less flexible. It would be good to unify zipfile and tarfile 
abilities. set_attrs also controls setting file owner and time. When we restore 
unsafe uid/gid/sticky bits, it would be worth to restore also file owner. And 
it would be not bad to restore file time.

--
assignee:  - serhiy.storchaka
nosy: +lars.gustaebel, serhiy.storchaka
versions: +Python 3.5 -Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[William Ehlhardt]

Changes by William Ehlhardt williamehlha...@gmail.com:


--
nosy: +Orborde

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Claudiu Popa]

Changes by Claudiu Popa pcmantic...@gmail.com:


--
stage:  - patch review

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Glenn Jones]

Glenn Jones added the comment:

Patch cleaned up based on previous comments.

--
Added file: http://bugs.python.org/file34873/issue15795_cleaned.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Claudiu.Popa]

Claudiu.Popa added the comment:

Hello. I added a couple of comments to your latest patch.

--
nosy: +Claudiu.Popa

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Glenn Jones]

Glenn Jones added the comment:

Patch with docs and tests fixed

--
Added file: http://bugs.python.org/file34893/issue15795_test_and_doc_fixes.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Glenn Jones]

Glenn Jones added the comment:

Here is an updated patch that applies cleanly to head. Tests pass against head 
of repo.

--
nosy: +Glenn.Jones
Added file: http://bugs.python.org/file34852/issue15795_updated.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

R. David Murray added the comment:

Thanks.

The patch contains a number of lines that are not wrapped to 80, which is one 
of our requirements.  It would be great to get that fixed.  (In the 
documentation, you can use \ to wrap the prototype line.)

There is non-ascii in one place in the documentation...probably an em-dash, 
which is written in sphinx as '---'.

Also, please remove the news entry from the patch, it will just make it harder 
to apply (and is in the wrong place anyway...we add entries at the top of the 
appropriate section, not the bottom).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] distutils ignores file permissions

[Garrett Cooper]

Garrett Cooper added the comment:

The whole permissions setting operation seems a bit convoluted.

I was hoping there was something formalized with install_data.py where I could 
specify a default or fine-grained user/group/mode for files, but it doesn't 
appear to be possible. I'll investigate applying a custom rule after install is 
run, but I would prefer for this to be formalized in the future.

--
nosy: +yaneurabeya

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Ronald Oussoren]

Ronald Oussoren added the comment:

On first glance the patch looks good. I haven't tested it with the current 
trunk though.

--
nosy: +ronaldoussoren

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[anatoly techtonik]

Changes by anatoly techtonik techto...@gmail.com:


--
nosy: +techtonik

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[anatoly techtonik]

anatoly techtonik added the comment:

There should be an easy way to restore file attributes.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Cédric de Saint Martin]

Changes by Cédric de Saint Martin ced...@desaintmartin.fr:


--
nosy: +desaintmartin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Aaron Train]

Aaron Train added the comment:

Thanks for the patch. Is this going to be resolved soon?

--
nosy: +Aaron.Train

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

R. David Murray added the comment:

OK, so this is an enhancement to specifically allow preservation of unsafe 
permissions?

Adding the nosy list from issue 3394.

--
nosy: +cbrannon, pitrou, swarren
type: behavior - enhancement
versions:  -Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Alexey Boriskin]

Changes by Alexey Boriskin sun.v...@gmail.com:


--
hgrepos: +147

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
hgrepos:  -147

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Alexey Boriskin]

Alexey Boriskin added the comment:

I'm attaching a patch, which solves the issue. Patch intoduces new argument 
preserve_permissions for extract and extractall methods. That argument may 
accept one of the three values: do not preserve permissions, preserve a safe 
subset of them or preserve all permissions. Three constants introduced for 
these options. Patch also contains test and docs. Tests pass for me on OS X 
10.5, but I'm not sure if they'll pass on other operating systems.

--
keywords: +patch
Added file: http://bugs.python.org/file27086/issue15795.patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[Alexey Boriskin]

New submission from Alexey Boriskin:

Zipfile._extract_member does not preserve file permissions while extracting it. 
As may be seen at link[1], raw open() is used and no os.chmod() applied after 
that, therefore any permission data stored in zipfile is dropped and file is 
created with default permission depending on current user's umask.

[1] http://hg.python.org/cpython/file/52159aa5d401/Lib/zipfile.py#l1251

--
components: Library (Lib)
messages: 169233
nosy: uruz
priority: normal
severity: normal
status: open
title: Zipfile.extractall does not preserve file permissions
type: behavior
versions: Python 2.7, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15795] Zipfile.extractall does not preserve file permissions

[R. David Murray]

R. David Murray added the comment:

Does this have any relationship to issue 3394?  From the discussion on that 
issue it sounds like zipfile is doing things with external_attributes if it is 
set.  But I don't know much about zipfile internals.

--
nosy: +r.david.murray

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15795
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] distutils ignores file permissions

[Patrick Andrew]

Changes by Patrick Andrew pand...@isilon.com:


--
components: +Distutils2 -Distutils
nosy: +alexis
title: build_module failure - distutils ignores file permissions
versions: +3rd party -Python 2.7

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[Éric Araujo]

Éric Araujo mer...@netwok.org added the comment:

FTR it looks like 
http://mail.python.org/pipermail/python-list/2009-January/1188084.html was the 
original report for this.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
keywords: +easy
stage:  - unit test needed
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
components: +Distutils2 -Distutils
versions: +Python 2.5, Python 2.6, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
nosy: +merwok

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reading and setting file permissions programmatically

[Cameron Pulsford]

Sorry to flood the list but my google fu isn't up to par today I guess.
Basically, is it possible to read the permissions on one file and then set
the permissions of another file to the ones we just read? os.dup2 seemed
like it would work but I might not be using it correctly.

I know there is os.chmod, but I haven't found the equivalent to read
permissions. Preferably this would work on unix and windows too.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reading and setting file permissions programmatically

[MRAB]

Cameron Pulsford wrote:

Sorry to flood the list but my google fu isn't up to par today I guess.

Basically, is it possible to read the permissions on one file and then 
set the permissions of another file to the ones we just read? os.dup2 
seemed like it would work but I might not be using it correctly.


I know there is os.chmod, but I haven't found the equivalent to read 
permissions. Preferably this would work on unix and windows too.



os.stat(path).st_mode
--
http://mail.python.org/mailman/listinfo/python-list

Re: Reading and setting file permissions programmatically

[Kushal Kumaran]

On Thu, Jun 18, 2009 at 2:05 AM, Cameron
Pulsfordcameron.pulsf...@gmail.com wrote:
 Sorry to flood the list but my google fu isn't up to par today I guess.
 Basically, is it possible to read the permissions on one file and then set
 the permissions of another file to the ones we just read? os.dup2 seemed
 like it would work but I might not be using it correctly.
 I know there is os.chmod, but I haven't found the equivalent to read
 permissions. Preferably this would work on unix and windows too.

shutil.copymode

-- 
kushal
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() also seems to set file permissions

[tinnews]

Aahz a...@pythoncraft.com wrote:
 In article gksdnzap17601g7unz2dnuvz_jti4...@posted.visi,
 Grant Edwards  inva...@invalid wrote:
 On 2009-04-25, tinn...@isbd.co.uk tinn...@isbd.co.uk wrote:
 
  Where should one report bugs/errors in python library classes?
 
 http://docs.python.org/bugs.html
 
 That's for doc bugs; regular bugs go to bugs.python.org (which is
 currently down due to hardware problems).

No, it's a page that tells you how to report bugs, it directs you to
bugs.python.org which, as you say, is dead at the moment.

-- 
Chris Green

--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() also seems to set file permissions

[Aahz]

In article gksdnzap17601g7unz2dnuvz_jti4...@posted.visi,
Grant Edwards  inva...@invalid wrote:
On 2009-04-25, tinn...@isbd.co.uk tinn...@isbd.co.uk wrote:

 Where should one report bugs/errors in python library classes?

http://docs.python.org/bugs.html

That's for doc bugs; regular bugs go to bugs.python.org (which is
currently down due to hardware problems).
-- 
Aahz (a...@pythoncraft.com)   * http://www.pythoncraft.com/

If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur.  --Red Adair
--
http://mail.python.org/mailman/listinfo/python-list

mailbox.mbox.add() also seems to set file permissions

[tinnews]

mailbox.mbox.add() has *another* 'quirk'.  When it adds a message to
an mbox file it seems to set the permissions to 0755 which is quite
wrong for mbox files.  I get the feeling that the mbox versions of the
functions are just bodged maildir ones.  If one was creating a maildir
it *might* make some sense setting to 0755.

Where should one report bugs/errors in python library classes?

-- 
Chris Green

--
http://mail.python.org/mailman/listinfo/python-list

Re: mailbox.mbox.add() also seems to set file permissions

[Grant Edwards]

On 2009-04-25, tinn...@isbd.co.uk tinn...@isbd.co.uk wrote:

 Where should one report bugs/errors in python library classes?

http://docs.python.org/bugs.html

-- 
Grant Edwards   grante Yow! Gee, I feel kind of
  at   LIGHT in the head now,
   visi.comknowing I can't make my
   satellite dish PAYMENTS!
--
http://mail.python.org/mailman/listinfo/python-list

[issue5300] Distutils ignores file permissions

[George Sakkis]

George Sakkis george.sak...@gmail.com added the comment:

 what is your use case of having executable file here ?

 I'd use the 'scripts' metadata for that ?

For one thing they are external binaries, not python scripts, and second
they are used internally only (through Subprocess), they are not
supposed to be called directly by clients.

 But How do you handle the overwrite of a read-only file in your code 
 then ?

I didn't, all my files were writable (by me), but if I had to, I'd look
at tweaking the directory write permissions; as I mentioned, I don't
think file permissions affect whether you can delete the file.

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[George Sakkis]

New submission from George Sakkis george.sak...@gmail.com:

Distutils ignores file permissions when copying modules and package_data
files to the build directory, and consequently to the installation
directory too. According to an XXX comment at
distutils/command/build_py.py, this is deliberate so that the built
files are not read-only, which would be a nuisance when rebuilding. This
problem though could be solved by just setting the write flag for the
user (chmod u+w) instead of overwriting all the flags. In my case, some
executable files ceased to be executable after installation.

I believe that the default behavior should be changed to preserve all
permissions, with the possible exception of setting u+w. Even that might
be unnecessary; AFAIK to delete a file you need write permissions only
to its parent directory, not to the file itself.

Even if the current behavior is deemed correct, at the very least the
code should be refactored to allow easy overriding. Currently
build_module and build_package_data pass preserve_mode=False in their
body, so I had to copy and paste the whole methods just to set
preserve_mode=True.

--
assignee: tarek
components: Distutils
messages: 82372
nosy: gsakkis, tarek
severity: normal
status: open
title: Distutils ignores file permissions
type: behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5300] Distutils ignores file permissions

[Tarek Ziadé]

Tarek Ziadé ziade.ta...@gmail.com added the comment:

 I believe that the default behavior should be changed to preserve 
 all permissions, with the possible exception of setting u+w. 
 Even that might be unnecessary; AFAIK to delete a file you need 
 write permissions only to its parent directory, not to the 
 file itself.

The u+w setting could also be done on the fly by copy_file at
installation time. e.g. when overwriting a read-only file.


 In my case, some 
  executable files ceased to be executable after installation.

what is your use case of having executable file here ?

I'd use the 'scripts' metadata for that ?


 Even if the current behavior is deemed correct, at the very least 
 the code should be refactored to allow easy overriding.
 Currently build_module and build_package_data pass 
 preserve_mode=False in their
 body, so I had to copy and paste the whole methods 
 just to set preserve_mode=True.

But How do you handle the overwrite of a read-only file in your code then ?

--
versions: +Python 2.7, Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5300
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Preserving file permissions with distutils

[George Sakkis]

I'm trying to use distutils to install some package data and
additional files, some of which may be executable. It turns out that
distutils does not preserve the permissions. Digging in the code,
there is the following comment on distutils/command/build_py:

# XXX copy_file by default preserves mode, which appears to be
the
# wrong thing to do: if a file is read-only in the working
# directory, we want it to be installed read/write so that the
next
# installation of the same module distribution can overwrite
it
# without problems.  (This might be a Unix-specific issue.)
Thus

If the only reason for not preserving the mode is ensuring it's read/
write, why not preserve the rest permissions and set the write flag
for the owner ? The comment continues:

# we turn off 'preserve_mode' when copying to the build
directory,
# since the build directory is supposed to be exactly what the
# installation will look like (ie. we preserve mode when
# installing).

But installing copies from the build dir which has forgotten the
original permissions, so there is no actual preservation! Am I reading
this wrong or should I submit a bug report ?

George
--
http://mail.python.org/mailman/listinfo/python-list

Re: Checking File permissions

[Tal Einat]

Anoop wrote:
 Hi All

 Please tell me how to check the existence of a file and the read
 permission to the file using python script

 Thanks for ur inputs

 Anoop

os.access(path, mode) does just this, check it out.

Cross-platform-ness isn't a problem, the docs say it is available for
Windows, Unix and Mac, and I've used it without a hitch on Win2k, WinXP
and various Linux and Unix platforms.

 help(os.access)
Help on built-in function access in module nt:

access(...)
access(path, mode) - 1 if granted, 0 otherwise

Use the real uid/gid to test for access to a path.  Note that most
operations will use the effective uid/gid, therefore this routine
can
be used in a suid/sgid environment to test if the invoking user has
the
specified access to the path.  The mode argument can be F_OK to
test
existence, or the inclusive-OR of R_OK, W_OK, and X_OK.

-- 
http://mail.python.org/mailman/listinfo/python-list

Checking File permissions

[Anoop]

Hi All

Please tell me how to check the existence of a file and the read
permission to the file using python script

Thanks for ur inputs

Anoop

-- 
http://mail.python.org/mailman/listinfo/python-list

Checking File permissions

[Anoop]

Hi All

Please tell me how to check the existence of a file and the read
permission to the file using python script

Thanks for ur inputs

Anoop

-- 
http://mail.python.org/mailman/listinfo/python-list

Checking File permissions

[Anoop]

Hi All

Please tell me how to check the existence of a file and the read
permission to the file using python script

Thanks for ur inputs

Anoop

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Checking File permissions

[Avell Diroll]

Anoop wrote:
 Please tell me how to check the existence of a file and the read
 permission to the file using python script

You can check the os module (os.stat comes to mind).

For an exemple you can have a look at :
http://www.pixelbeat.org/talks/python/ls.py

Regards,

Avell
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Checking File permissions

[Larry Bates]

Note: You really don't have to post the same question
3 times (2 in response to yourself).

import os

if os.path.exists(pathname):
  do something

To see if a file is writeable:

import stat

def iswriteable(path):
mode=os.stat(path)[stat.ST_mode]
return bool(stat.S_IMODE(mode)  stat.S_IWRITE)


Larry Bates

Anoop wrote:
 Hi All
 
 Please tell me how to check the existence of a file and the read
 permission to the file using python script
 
 Thanks for ur inputs
 
 Anoop
 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Checking File permissions

[Lawrence D'Oliveiro]

In message [EMAIL PROTECTED], Anoop
wrote:

 Please tell me how to check the existence of a file and the read
 permission to the file using python script

Without knowing what your precise needs are, the best way is to open the
file and try to read from it. If that succeeds, then you've got read
access.

Checking permissions as a separate step from opening the file exposes your
code to a race condition where the permissions may be OK during the initial
check, but then change to deny access before the subsequent open.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Rene Pijlman]

John Salerno:
I always read about how you need to set certain file permissions (for 
cgi files, for example), but it's never been clear to me *how* you do 
this. I know you can run the line

chmod 755 scriptname.py

but *where* do you run this? 

This is a Unix/Linux command. You run it in a shell login on the server
(e.g. in Putty, SecureCRT, or some other ssh client you're using).

Is there a way to put the above line within the script perhaps, so that 
the script sets its permission automatically?

Not in the script itself via cgi of course, because it needs certain
permissions before it can be run as cgi script. But you could put the
command in an installation script that installs the cgi script.

-- 
René Pijlman
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Daniel Nogradi]

 I always read about how you need to set certain file permissions (for
 cgi files, for example), but it's never been clear to me *how* you do
 this. I know you can run the line

 chmod 755 scriptname.py

 but *where* do you run this? Is this done on your personal system, or on
 the server? What if you are using Windows? If it's done on the server,
 how do you do it?

 The only way I've figured out so far how to do this is to upload my cgi
 files to my server, then within my FTP program I right-click the file
 and change its permission number that way, but that seems an inefficient
 way to do it, especially having to do it each time.

 Is there a way to put the above line within the script perhaps, so that
 the script sets its permission automatically? Or do certain editors
 allow you to save files with a predetermined permission?

 Aside from my right-clicking method, I don't know how else to do it.

I guess this would be a good starting point:

http://www.linuxcommand.org/man_pages/chmod1.html

In short, chmod refers to local files so wherever you run it it will
refer to files on that machine. You run it simply by typing it in a
shell as a user who has privilage to perform the operatation, which
can mean you have to be an owner of the file but if you are root you
can do it in any case. Depending on your ftp, scp, http or whatever
method you use to transfer files the file permissions may or may not
change during the transfer. If permissions are kept intact you can
chmod on your local machine and then transfer, if they are not then
you transfer first and chmod on the server. When you transfer files
from a windows machine to *nix it again depends on the particular
method you choose how the permissions will be set.

There is no way of putting this permission information into the file
itself but some (most?) editors can be set to save the file with a
permission of your choice.

Hope this helps.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[John Salerno]

Daniel Nogradi wrote:

 In short, chmod refers to local files so wherever you run it it will
 refer to files on that machine. You run it simply by typing it in a
 shell as a user who has privilage to perform the operatation, which
 can mean you have to be an owner of the file but if you are root you
 can do it in any case. Depending on your ftp, scp, http or whatever
 method you use to transfer files the file permissions may or may not
 change during the transfer. If permissions are kept intact you can
 chmod on your local machine and then transfer, if they are not then
 you transfer first and chmod on the server. When you transfer files
 from a windows machine to *nix it again depends on the particular
 method you choose how the permissions will be set.

Thanks, but I'm still a little confused. Since I'm running Windows, I 
assume that I can't run the chmod line on my own computer. My web server 
uses Unix, but is it possible for me to have access to a command line 
for the server? I didn't know that was possible for basic web hosting 
plans (I'm using 1and1 right now).

I suppose I could write a script that would set the permissions of all 
the files in a particular folder on my computer to 755, but is there a 
Windows equivalent command for chmod to do this? Or am I stuck having to 
do it on the server side?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Diez B. Roggisch]

 I suppose I could write a script that would set the permissions of all 
 the files in a particular folder on my computer to 755, but is there a 
 Windows equivalent command for chmod to do this? Or am I stuck having to 
 do it on the server side?

The chmod has to be executed on the machine the file resides on - aka 
the server. If your plan includes a ssh-account you can use that. 
Otherwise you might be able to create an ftplib-based script that will 
automate this over ftp.

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Daniel Nogradi]

  In short, chmod refers to local files so wherever you run it it will
  refer to files on that machine. You run it simply by typing it in a
  shell as a user who has privilage to perform the operatation, which
  can mean you have to be an owner of the file but if you are root you
  can do it in any case. Depending on your ftp, scp, http or whatever
  method you use to transfer files the file permissions may or may not
  change during the transfer. If permissions are kept intact you can
  chmod on your local machine and then transfer, if they are not then
  you transfer first and chmod on the server. When you transfer files
  from a windows machine to *nix it again depends on the particular
  method you choose how the permissions will be set.

 Thanks, but I'm still a little confused. Since I'm running Windows, I
 assume that I can't run the chmod line on my own computer.

Correct, chmod is a *nix command.

 My web server
 uses Unix, but is it possible for me to have access to a command line
 for the server?

This depends on your arrangements with your web server provider.
Perhaps you are allowed to ssh into that machine, perhaps not, you
need to ask your provider. In case you can use ssh, then you can log
in with putty (an ssh client for windows, grab it from here:
http://www.chiark.greenend.org.uk/~sgtatham/putty/) and you will have
a command line on the server so you can run chmod there.

 I didn't know that was possible for basic web hosting plans (I'm using 1and1 
 right now).

I have absolutely no experience with public web hosting but I guess
some might provide ssh-ing possibilities although I imagine most
don't.

 I suppose I could write a script that would set the permissions of all
 the files in a particular folder on my computer to 755, but is there a
 Windows equivalent command for chmod to do this?

I have next to zero experience with windows but as far as I know
windows doesn't have file permissions at all (anyone, please correct
me if I'm wrong :)) so in windows land it doesn't make any sense to
change file permissions. Even if it has some sort of a notion of
file permissions I wouldn't know how that gets translated into unix.

 Or am I stuck having to do it on the server side?

I guess so. But that's not a terribly big problem even if you can't
use ssh. What I would do is write a script (in python of course :))
that does the file permission changing and run that script over the
web. Since this can have serious security implications my strategy
would be to place this script somewhere which is not reachable through
the web and only relocate it to a web accessible directory when you
want to run it over the web, and when you are done, you place it back
to its secure location so nobody can reach it. You can find out how to
write this script from http://docs.python.org/lib/os-file-dir.html

HTH :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Edward Elliott]

John Salerno wrote:
 Thanks, but I'm still a little confused. Since I'm running Windows

You misplaced your period, it goes at the end of that line. ;)

 assume that I can't run the chmod line on my own computer. 

Sure you can, install cygwin.  chmod only affects files on your computer,
and won't alter the Windows permissions (which use a different scheme), but
you can do it.

 My web server 
 uses Unix, but is it possible for me to have access to a command line
 for the server? I didn't know that was possible for basic web hosting
 plans (I'm using 1and1 right now).

It is entirely possible (indeed, I don't know how most things would ever get
done without it).  Most basic hosting plans however don't provide shell
access.

 I suppose I could write a script that would set the permissions of all
 the files in a particular folder on my computer to 755, but is there a
 Windows equivalent command for chmod to do this? Or am I stuck having to
 do it on the server side?

1. Settings permissions on your computer won't do a thing.
2. There's probably a Windows-equiv of chmod for your own files, but it
won't affect files placed on another machine.
3. You're stuck having to do it on the server side.  Now a good ftp program
can automate this for you, but it's still your job, not the servers.

These sound like good questions for your hosting provider, or failing that,
google.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Edward Elliott]

Daniel Nogradi wrote:
 I have next to zero experience with windows but as far as I know
 windows doesn't have file permissions at all (anyone, please correct
 me if I'm wrong :)) so in windows land it doesn't make any sense to
 change file permissions. 

Actually Windows has a quite good permission scheme, with full owner/group
ACLs and granular permissions for read, write, append, delete, and several
others I can't recall.  The problem is no one uses them much.  The
manipulation tools are a pain, and developers routinely ignore them
(including Microsoft's own developers, although I hear they've gotten much
better lately).

 I guess so. But that's not a terribly big problem even if you can't
 use ssh. What I would do is write a script (in python of course :))
 that does the file permission changing and run that script over the
 web. Since this can have serious security implications my strategy 
 would be to place this script somewhere which is not reachable through
 the web and only relocate it to a web accessible directory when you
 want to run it over the web, and when you are done, you place it back
 to its secure location so nobody can reach it. 

You're right about the security concerns, but your solution sounds like more
trouble than it's worth.  With a bit more effort, you could write a local
python script that acts as an ftp client and applies permissions remotely. 
But why bother when a good ftp client already has that built-in (and is
much less likely to contain destructive bugs).

 You can find out how to
 write this script from http://docs.python.org/lib/os-file-dir.html

You're worried about security and you turn a novice with a scripting
language loose in the briar patch of unix permissions, on a remote server
no less?  And I thought I was sadistic! :)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Kirk McDonald]

Daniel Nogradi wrote:
 I have next to zero experience with windows but as far as I know
 windows doesn't have file permissions at all (anyone, please correct
 me if I'm wrong :)) so in windows land it doesn't make any sense to
 change file permissions. Even if it has some sort of a notion of
 file permissions I wouldn't know how that gets translated into unix.

This is getting a little off-topic, I admit, but the NT-derived versions 
of Windows do indeed have file permissions. The Windows-equivalent of 
chmod (and chown) is cacls (Change Access Control Lists):

http://www.ss64.com/nt/cacls.html

In essence, each file has an owner and a list of other users and groups, 
who may each have Full control (meaning they can change permissions), 
read-only, write-only, read-write, or no access.

Windows 95 and its descendants don't have permissions any more than DOS 
does. (Except with respect to Windows network file-sharing.)

(Heh, I checked just before posting this and someone beat me to it. 
Here's my post anyway.) :-)

-Kirk McDonald
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[John Salerno]

Daniel Nogradi wrote:

 This depends on your arrangements with your web server provider.
 Perhaps you are allowed to ssh into that machine, perhaps not, you
 need to ask your provider. In case you can use ssh, then you can log
 in with putty (an ssh client for windows, grab it from here:
 http://www.chiark.greenend.org.uk/~sgtatham/putty/) and you will have
 a command line on the server so you can run chmod there.

Turns out that my web hosting company provides ssh access on the next 
highest plan and up, but not mine. :)

Oh well, I think I'll explore FileZilla a little more and see if there's 
more of an automated way to do it than just right-clicking each file (or 
even right-clicking multiple files at once, if possible). It shouldn't 
be too big of a deal anyway, but I'm always after more automated ways to 
do things...call me lazy! :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: setting file permissions on a web server

[Martin P. Hellwig]

John Salerno wrote:
cut

Most FTP servers do allow to use chmod in a ftp session, although you're 
client must support it. See for example a cli ftp client (and server) on 
FreeBSD.

 [EMAIL PROTECTED]:~$ ftp ftp.xs4all.nl
 Connected to ftp2.xs4all.nl.
 220 XS4ALL ftpd DCLXVI
 Name (ftp.xs4all.nl:mhellwig):
 331 Password required for mhellwig.
 Password:
 230 User mhellwig logged in.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ftp ls MHellwigCV_02_10_01.pdf
 150 Opening ASCII mode data connection for file list
 --   1 mhellwig user   211102 May 19  2003 MHellwigCV_02_10_01.pdf
 226 Transfer complete.
 ftp chmod 400 MHellwigCV_02_10_01.pdf
 200 SITE CHMOD command successful
 ftp ls MHellwigCV_02_10_01.pdf
 150 Opening ASCII mode data connection for file list
 -r   1 mhellwig user   211102 May 19  2003 MHellwigCV_02_10_01.pdf
 226 Transfer complete.
 ftp

See?

-- 
mph
-- 
http://mail.python.org/mailman/listinfo/python-list

setting file permissions on a web server

[John Salerno]

I always read about how you need to set certain file permissions (for 
cgi files, for example), but it's never been clear to me *how* you do 
this. I know you can run the line

chmod 755 scriptname.py

but *where* do you run this? Is this done on your personal system, or on 
the server? What if you are using Windows? If it's done on the server, 
how do you do it?

The only way I've figured out so far how to do this is to upload my cgi 
files to my server, then within my FTP program I right-click the file 
and change its permission number that way, but that seems an inefficient 
way to do it, especially having to do it each time.

Is there a way to put the above line within the script perhaps, so that 
the script sets its permission automatically? Or do certain editors 
allow you to save files with a predetermined permission?

Aside from my right-clicking method, I don't know how else to do it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: File Permissions

[Christos Georgiou]

On Fri, 10 Mar 2006 16:43:15 +0200, rumours say that Juho Schultz
[EMAIL PROTECTED] might have written:

VJ wrote:
 Hi All
 
 Basically i want to write into a file .If the permissions are not there
 then print a error message.
 How do i achive this ???
 
 Thanks,
 VJ
 
One way would be a try-except block, and leave the permission checking 
error message generation, etc. to the operating system.

try:
 outfile = file(outfilename,w)
except IOError, errormsg
 print Could not write to file %s: %s % (outfilename, errormsg)

As a word of caution: the OP is checking for the permissions of an
*existing* file.  Both Juho's and Sybren's suggestions *destroy* the file's
contents.

So, VJ, I'd suggest the following change:

Open the file for read write

outfile= open(outfilename, r+b) # I assume binary

and later on catch errors in .write operations.
-- 
TZOTZIOY, I speak England very best.
Dear Paul,
please stop spamming us.
The Corinthians
-- 
http://mail.python.org/mailman/listinfo/python-list