Hi all,

Happy celebrations for the end of 2009!

I've got just another esoteric question.

I have a linux box which was running mandriva 2006 just well.

I recently upgraded directly to mandriva 2008.0 and then immediately again to mandriva 2009.1.

All went quite well (yes, really!), except that a user cron script started to fail : "command not found".

I finally understood that a command used in the script was not in the PATH any longer.

Nothing changed in the configuration during the upgrade process (neither global path in /etc/profile or whatever, nor user path in ~/.bashrc and other files...).

The command is still there, in its local directory (it's not been installed using rpm).

The trick is that the script is actually called through a sudo:

* Alice's crontab calls "sudo -u Bob /usr/local/Bob/script"

* /usr/local/Bob/script calls /usr/local/another/command

* /usr/local/another is in Bob's path (more precisely exported from ~Bob/.bashrc) but NOT in Alice's path.

It seems that under mandriva 2006, all went well (sudo apparently called the script with Bob's environment, at least the Bob's Path).

But since the upgrade, Alice gets "command not found".

After struggling hard with sudo man documentation, I only found:

* sudo -i -u Bob -- -c /usr/local/Bob/script : indeed loads target user's environment, but this also calls a shell (instead of /usr/local/Bob/script which is executed in this shell afterward), so that I would have to change the sudo rule allowing Alice to execute a whole bash and not only the desired script (which is a security hole for Bob)

* sudo -E -u Bob /usr/local/Bob/script (along with sudoers settings about reset_env, setenv, etc.) : this is only to make variables from calling user available to the target user, and I don't want to change calling user's environment, just use the target user's env.

* sudo -u Bob VAR=value /usr/local/Bob/script : this could only allow me to "simulate" Bob's PATH, not read it's actual value... what if it changed in the future? Alice wants something dynamic...

My main is question is HOW ALICE MAY CALL "sudo -u Bob /usr/local/Bob/script" USING BOB'S environment?

(it was apparently possible earlier, it may have changed because of security considerations, but what is the new syntax then to force this behavior?)

Thanks in advance,

Best regards,

The thought occurs why not have bob call bobs script from his crontab? You could also use -H and have the script source ~/.bashrc / whatever files it needs as it's first action to give it bob's enviroment.

1 members found this post helpful.

I know it doesn't exactly answer the question, but do you really need the user Bob's environment to run the script? If not, I can think of three possible quick fixes.

1. Add the script to the user Bob's crontab instead.
2. Add the path to /usr/local/another/command to Alice's path
3. Hardcode the path to /usr/local/another/command in the script (/usr/local/Bob/script).

I'm fairly sure that the sudo program was changed quite a bit over the last few years to tighten up the loading of environmental variables and the like. Frustrating though!

Cheers,
Steve

0 members found this post helpful.

Hi,

thanks for quick replies.

what is really frustrating are people trying first to workaround rather than debug...

yes, really, why would I bother running Bob's script from Alice's crontab if I could do it from Bob's crontab directly? Of course, it was so simple, so that either I'm stupid or I had good reasons to do that...

I'll try the -H option, though, but Alice cannot modify Bob's script to force it source ~/.bashrc ... so I'm not sure it will do the trick.

cheers,

I think the trouble is that some of us can see that you are (unintentionally) making life unnecessarily complicated for yourself.

Every linux problem will have many solutions, some simple, straightforward, and "elegant", others complex, untidy and "ugly".

You seem to want to follow the latter path.

I don't understand why you have the directory /usr/local/Bob/

I don't understand why you want Alice to sudo as Bob. For her to be able to do this, she needs to know Bob's password (and I don't think you can do this from a crontab entry anyway), or you have to have set up sudo in an insecure way: Ugly.

Local scripts that are going to be run by more than one user can go in /usr/local/bin.
They need to be owned by root and have permissions of 755
That way, anyone can run them, but only root can change them (security).
If the script needs a special environment or $PATH, it can set it up itself.

Alice or Bob can both run the script with /usr/local/bin/scriptname
but as /usr/local/bin is usually in all user's PATHs they can just call it with scriptname

Note that crontabs run from within a restricted PATH and should call the script with its full pathname.

You could set up root's crontab to run a script that will su to any user(s) and execute whatever scripts you like as that user. Only root should be allowed that privilege.

If you posted a bit more about what this mysterious script of Bob's does, I am sure we could help you further.

0 members found this post helpful.

sorry tredegar but:

* I think you should apply your judgment to your own answer (which holds many errors demonstrating your knowledge of linux might be not such as you might think)...

* why are you so quick at judging other people instead of just trying to answer their question (or keeping silent if you don't know the answer)?

* yes, I could describe my whole situation, including my particular security policy, the interactions that are wanted or not between my users, and even their birthdate! and sure you will get a bunch of litterature to keep you awake at nights... but what for?

why not just keep confident in me, and just either answer my question (how to restore the sudo behavior I was used to) or (perhaps) tell me there is no solution because (perhaps) sudo has been changed so that it is a feature and not a bug that such a behavior is now impossible to reproduce?

perhaps in fact, it is I who gave TOO MUCH details trying to give you as much clues as I could to help you help me... sorry in such case, it's a good lesson for me.

to conclude, in the past, I used to find in this forum many answers to the linux questions I had without even asking them, and I had a good opinion of it, so that I finally created a profile and posted this month two of my remaining problems.

but in both cases, I just received noise from people probably just wanting to increase their number of posts at all costs to get I-dunno-what-privilege rather than really helping.

this community does not worth the time,

so long.

The problem is actually to little detail, there are a few valid reasons I can think of as to why you would want to perform an operation like that, but there are far more invalid reasons or 'bad' reasons. We try to help people find the best solution we can when possible. The fact that you're here asking for a solution and you didn't already rule out items that are in the man page says you may be fairly new to linux or just not familiar with the cli or any multitude of reasons. In addition to that there are things we are not allowed to help with based on the rules of the site. It's hard to provide a good answer when you're not provided all the information.