changing passwd permission

Maximus_el

New Member
Joined
Oct 12, 2024
Messages
12
Reaction score
14
Credits
93
i dont remember why i chmod passwd to 744, its not even executable. however i did this few days ago and since then i also noticed something strange in RHSM and subscription-manager but i was too busy to care.
anyway, i needed to log to a usr and the system couldn't resolve its name "or any other name" , then GNOME didn't lunch
its just look like 744 is preventing others from reading the file, i dont know why.
my question is why? i had to return it to 644 so solve the issue.
 
Last edited:


When you set the file permissions to 744, you gave the owner full control to read, write, and run the file. Doing so limited access for everyone else, meaning other users and system services like gnome can't read the /etc/passwd file.
 
Some distro's block this with appArmor and SELinux also.
 
i dont remember why i chmod passwd to 744, its not even executable. however i did this few days ago and since then i also noticed something strange in RHSM and subscription-manager but i was too busy to care.
anyway, i needed to log to a usr and the system couldn't resolve its name "or any other name" , then GNOME didn't lunch
its just look like 744 is preventing others from reading the file, i dont know why.
my question is why? i had to return it to 644 so solve the issue.
The reason the passwd file is given permissions 644 rather than executable permissions almost certainly has to do with security. Since the file needs to be able to be read by other applications, for efficiency it's made readable by everyone, but making it executable would increase the possibility of its use by a malicious agent, if they could engineer a means of executing it. An inspection of the passwd file normally shows the shell of the user, and of root, both of which are executable shells rather than "nologin", so there would be an increased attack surface for an intruder to take advantage of, if the file itself was executable. Using what is executable within the file, as an intruder, to access the system would be a serious security breach. The specifics of how that could be achieved is another matter :).
 
The reason the passwd file is given permissions 644 rather than executable permissions almost certainly has to do with security. Since the file needs to be able to be read by other applications, for efficiency it's made readable by everyone, but making it executable would increase the possibility of its use by a malicious agent, if they could engineer a means of executing it. An inspection of the passwd file normally shows the shell of the user, and of root, both of which are executable shells rather than "nologin", so there would be an increased attack surface for an intruder to take advantage of, if the file itself was executable. Using what is executable within the file, as an intruder, to access the system would be a serious security breach. The specifics of how that could be achieved is another matter :).
is the concern because of the file includes shell? so this means the theory applies to files like shadow shells group in /etc, even .bashrc ?
 
Some distro's block this with appArmor and SELinux also.
i checked SELinux for denials related to the /etc/passwd with ausearch , journalctl and there is non. also there is no denials related to /etc/passwd in /var/log/audit/audit.log
 
is the concern because of the file includes shell? so this means the theory applies to files like shadow shells group in /etc, even .bashrc ?
The issue of granting passwd execute permissions, so far as I can see, as mentioned in post #4, is a problem in so far as a malicious agent: "could engineer a means of executing it". I wouldn't expect that's a trivial matter, and could only guess how it might be done at this point.

In relation to the other files mentioned in post #6, I expect they would also have a similar reason based around security as to why none of them has execute permission. In the case of /etc/shadow, on debian, only root can access that file, so it's been elevated I guess because it includes the actual hash of the root password which could be altered.

If you wanted to try and execute the /etc/passwd file, you might like to experiment with a script that alters the file in such a way as to make it an executable script itself based on its contents. Once that can be achieved, then the script can be made to do any number of things on a system. That, I think is part of the security issue.
 

Members online


Top