[Glass] problem with stone log and permissions :(

[Dale Henrichs via Glass]

On 02/07/2017 06:19 AM, Mariano Martinez Peck wrote:
> Hi Dale,
>
> I am reviving an old thread. I quote your most important part:
>
> -----
> /"I've looked at the c code and when we do a fork we do achdir() to 
> the `workingDirectory` and throw the error that you see if thechdir() 
> fails../
> /
> /
> /It looks like startstone does a fork using '.' as the working 
> directory so it is literally using the current directory (i.e., 
> environment variables are involved at all) when it does the fork. /
> /"/
> /-----/
> /
> /
> /
> /
> As you know, after I create a stone via `createStone` I do:
>
> sudo chown -R $gsDevKitUser:$stoneOSUser $GS_HOME/server/stones/myStone
>
> And then, all the starts/stops of stone, netldi and gems are triggered 
> with the OS user $stoneOSUse. So far so good. But I have 2 scenarios:
>
> 1) Me (a sysadmin) logs into the system with a given OS user. Say you 
> are ate /home/mariano. You do "sudo su $stoneOSUse" and then try to 
> start stone. That will fail, becasue current dir is "/home/mariano" 
> and $stoneOSUse does not have access to it. So..everything I do this I 
> must do a "cd" to a place that i know it can fork (like $GS_HOME).
>
> 2) Monit trying to start/restart my stuff. Same problem. Monit is 
> started by root and the given user $stoneOSUse cannot fork on the 
> current directory.
>
> I have been suffering this problem already with my `startAllStones` 
> and `stopAllStones` as well as with my `startSeasideGems`.
>
> Anyway, the workaround I did is pretty simple, and it's the place 
> where you do:
>
>
> # set up stone environment
> pushd $stonePath >& /dev/null
> source $stonePath/stone.env
> popd >& /dev/null
>
> I added a line "cd $stonePath" before that and everything works 
> correct. I cannot imagine GsDevKit_home code that would break if I 
> change working dir. Maybe there is, but I haven't faced it yet. If you 
> think we are safe and you think this is correct, then I could like to 
> add this to `startStone` and `stopStone` in a issue + PR.
>
> Another possibility would be to do it in a much generic place to avoid 
> modifying each script. Say..in `${GS_HOME}/bin/private/shFeedback`  we 
> could do "cd $GS_HOME" but maybe too risky ?
>
>
>
> Thoughts ?
>
I think it's a good idea ... you can get rid of the pushd as well ...

I think the changes should be done on a command by command basis ... 
There are certain commands like startTopaz that could produce arbitrary 
output files depending upon what code is executed and it may not be 
desirable to clump them all in the same directory ... it's annoying to 
have junk dropped into the current directory but it would even more 
annoying to not be able to control where the files get created ...

Dale


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170207/85639d8e/attachment.html>