|
Re^2: I need a user just for Perl script run from web browsers
by afoken (Chancellor) on Apr 29, 2022 at 09:32 UTC
|
Is there a minimal command I can use, so that Sally1 is able to have all the permissions that Johnny1 has?
Why not give them the same UID?
Because that would create a single user with two different login names. And that's a really bad idea, because user IDs and group IDs should be unique. If two users share a UID, which entry in /etc/passwd is used to find home directory and login shell? getpwuid and the underlying getpwuid both return a SINGLE record.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
|
|
If two users share a UID, which entry in /etc/passwd is used to find home directory and login shell?
Well during login, the login name is available, so this is used for the lookup in /etc/passwd to find the login environment.
However, I just did the experiment for the relevant portion (the output of top and ps, and indeed, the login name is not preserved. You get the first login name which matches the numerical user id, so for the original problem I agree: That's a bad idea.
| [reply]
[d/l] |
|
|
In the general case it is arguably a bad idea. However, in bartender1382's specific situation of wanting a user to own the apache processes it is fine, IMHO. Both users should never login and so should have /bin/false or similar as their login shell anyway. They can also happily share the same home dir.
Note that bartender1382 has given no background as to why on earth they want to do this in the first place. It does seem like making work for no good reason when there is a perfectly valid single-use user already dedicated to apache in pretty much every O/S. It sounds very much like an XY problem to me.
| [reply]
[d/l] |
|
|
specific situation of wanting a user to own the apache processes it is fine, IMHO
It might be fine from an admin point of view. However, from what haj has said, it doesn't seem to solve the OP's problem.
I just did the experiment for the relevant portion (the output of top and ps, and indeed, the login name is not preserved
The OP wants the username to appear in top so they can differentiate between their admin account and a user running the Perl script. At least, I think that's what they want to do.
I recall a long time ago being introduced to nobody that was a *nix user account for running Perl scripts on a webserver. I didn't understand it at the time I don't remember enough details to try and piece it together now but it might jog the memory of some experts in *nix is it is a possible solution.
| [reply] |
|
|
Note that bartender1382 has given no background as to why on earth they want to do this in the first place. It does seem like making work for no good reason when there is a perfectly valid single-use user already dedicated to apache in pretty much every O/S. It sounds very much like an XY problem to me.
Actually I did, I want a dedicated user to run all the perl scripts, so when I use the top command (debugging forks, etc.) it is easier of me to single outage processes for just that user.
Not sure who the "perfectly valid single-use user" that's already in existence.
Again, I am Johnny1 who setup the server, created paths, edited .htaccesses, installed all, etc. etc. But my knowledge in linux in limited to just that, setup. So if I could created that user, to place in the enviers file, it would just make my daily work easier.
| [reply] |
Re^2: I need a user just for Perl script run from web browsers
by bartender1382 (Beadle) on Apr 29, 2022 at 00:01 UTC
|
I put up the link in my OP, and fixed the error where I reference the enviers file.
Yet I can find no reason to understand why the I can't make a user gets assigned to all Perl scripts run remotely via the web browser?
Because even when I give that new user all the rights to the paths that some perl scripts write to, I still get a Permission denied error. And I have no idea why. | [reply] |
|
|
A quick way to test is to log in as the new user "sudo -u Sally1 bash" and then change to the same directory and try reading and writing the various paths that your script uses. Then, try running your script. (you can set environment variables to simulate the script being called by a web request)
| [reply] |
