[New rule] Octal literal for `chmod` mode bits

[opk12]

Summary

pathlib.Path('/file').chmod(444) means something different than what it seems, should be chmod(0o444).

Also, chmod of a decimal or hexadecimal literal is most likely unintentional, because it is are hard to read and the standard usage is octal. For example, telling the mode bits from 292 or 0x124 is not straightforward.

A new rule could look for a numeric literal and propose the octal form. There exist stat.S_* constants listed at os.chmod(), but honestly I'm not their fan, as the 3-digit version is cleaner and is standard in the POSIX world.

I don't have experience with the similar functions, but I guess the rule should also cover them.

• pathlib.Path.lchmod()
• os.chmod()
• os.fchmod()
• os.lchmod()

Docs

• Path.chmod()
• os.chmod()

[ntBre]

This makes sense to me. I think we should probably also allow the stat.* | ... case, but I think it makes sense to warn on other int literals.

[MichaReiser]

https://docs.astral.sh/ruff/rules/bad-file-permissions/ is related. We should ensure the two rules perform the check in the same places

[RazerM]

I have a proof of concept of this working and hope to open a PR soon™

crates\ruff_linter\resources\test\fixtures\ruff\RUF061.py:3:18: RUF061 Non-octal mode, did you mean 0o444?
  |
1 | import os
2 |
3 | os.chmod("/foo", 444)  # Error
  |                  ^^^ RUF061
4 | os.chmod("/foo", 0o444)  # OK
  |

[ntBre]

Awesome, thank you! Just a note if it's not too late already, I think RUF061-063 are all in use by existing PRs (#18233 (comment)). We can always renumber later, but RUF064 should be the next free code.