zhuyifei1999 added a comment.
oh, os.open default mode is 777. Why doesn't WSL have a sane umask?TASK DETAILhttps://phabricator.wikimedia.org/T212723EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: zhuyifei1999Cc: Framawiki, zhuyifei1999, Dvorapa, Xqt,
zhuyifei1999 added a comment.
Could it be https://github.com/wikimedia/pywikibot/blob/e57dbff2bf6d4dd719a6f576d96a3b285acbc4ea/pywikibot/config2.py#L1054:
if OSWIN32 or _filemode & 0o02 == 0:
with open(_filename, 'rb') as f:
exec(compile(f.read(), _filename, 'exec'), _uc)
else:
zhuyifei1999 added a comment.
Though, POSIX ACLs might be able to prevent reading 777 files; I have not looked into that. However, POSIX ACLs should not be 'enabled' for a clean install, and even if it's 'enabled' ls should show clearly that the file has ACLs.TASK
zhuyifei1999 added a comment.
mode 777 being un-readable is not POSIX-conformant and is not Linux bahavior. filesystem default to 777 is also not Linux bahavior (which is mode to open(2) - umask).
The paths in the traceback (/mnt/c/) looks like Windows Subsystem for Linux, and I suspect NTFS ACLs
Xqt added a comment.
it would be wise to document it somehow to prevent future problems.
Either this or the generating script should print an appropriate message (or both)TASK DETAILhttps://phabricator.wikimedia.org/T212723EMAIL
Wesalius added a comment.
In T212723#4855984, @Dvorapa wrote:
@Wesalius Then there are two possibilities:
a) you have bot.py, generate_user_files.py, pwb.py or config2.py in 777 and the user-config.py is created by those files with inherited permissions: you should reset permissions for these
Dvorapa added a comment.
@Wesalius Then there are two possibilities:
a) you have bot.py, generate_user_files.py, pwb.py or config2.py in 777 and the user-config.py is created by those files with permissions inherited: you should reset permissions for these files (ideally for all Pywikibot files)
