-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Executing /tmp/action #6
Comments
For the first issue you are completely right, I will fix it as soon as I can. I have no plans in fixing the second one, it is in fact normal functionality, as some scripts that would be useful in duress require root privileges (for example |
The stuff like As things stand, the more general-purpose use of the module is limited -- access to scripts can only be given to a small group of trusted users. This may not matter for folks travelling with their single-user laptops, but administrators running remotely-accessible multi-user Unix-servers may wish to restrict the module's use to the users' own files only. For example, a user travelling to Iran may need to wipe his
This increases the admin's workload -- it means, the admin needs to be able to carefully read each new script to vet it. It is bad enough having to do that for the If you still disagree, whether or not to change UID can be controlled by a command-line argument... |
I added use of FYI: http://superuser.com/questions/72164/panic-password-on-linux/1176739 |
First of all, the script's name should not be static (
/tmp/action
), but be constructed on the fly withmkstemp(3)
to avoid clashes, when multiple logins (by the same or different users) to the same host happen at the same time.Second, should not the code perform a
setuid(2)
afterfork()
to the user before invoking the script? Unless PAM somehow does this automatically, it seems like this is a major security flaw in the current implementation -- allowing users' scripts to run as root...The text was updated successfully, but these errors were encountered: