[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] change user when executing some script



2007/6/15, Bob Proulx <bob@proulx.com>:
Galevsky wrote:
> Many thanks for your comment and piece of code ;)

I would not want to have warned that the sky was falling without being
able to direct people to an underground bunker where they would be
safe.  :-)

Ya, but not the whole contributors do this way, so thanks again.

> In fact, I need my team to run a ruby tool,

Yeah!  Ruby!  Good stuff.  (I am just saying this to give market share
and positive feedback on this fine language.)

Well, as a professional developer -does not mean that I own superior
knowledge, but this is my job-, my opinion is that Ruby is young,
powerful, but face drawbacks. The lack of good documentation is a huge
problem. The half job of writing an API is writing doc, but lots of
docs are missing in Ruby world. There is a lot of people that use Ruby
as their first language, because Ruby brings simplified syntax.... but
they rush without general object oriented development basic knowledge.
Moreover, C++ can be equipped with Interface mechanism and all the
powerful stuff -e.g. mixins- provided by Ruby. (ObjectModeler
developed by Dassault System brings these features to a very-powerful
dev framework, used for CATIA software). And you have the more
professional hard-typing that allows dev to  build up huge softwares
together into a high-descriptive and formal-agreement dev environment.

> but $RUBYLIB and the main routine call is done into a setgid shell
> script.

I don't understand what you are describing here.  Of course $RUBYLIB
is used by ruby to locate 'required' files.  But suid does not apply
there.  Ruby itself will have a script entry point.

You're right. I can choose to apply setgid either on the script file
or the run.rb file (my entry point). But it is more convenient for me
to do that on the shell script since I can substitute run.rb with a
new version without paying extra care to its permissions (but I do
modifications under user myTeam). We also have the following tree for
the tools developed by the team:

~myTeam/tools/releases/anytool_version
~myTeam/tools/prod/anytool is a symlink to the anytool_version to ease
the move to new versions as well as the fall back in case of problem.
~myTeam/tools/prod/bin/anytool.sh is a symlink to
~myTeam/tools/prod/anytool/anytool/executable

Note that the users that want to use the tools developed by myTeam
just have to add ~myTeam/tools/prod/bin/ to their $PATH.

> The script belongs to special user and group: myTeam:myTeam,
> and all the members of the team have the ability to log as myTeam
> special user.

Is the set of your team members and the set of all local users on the
host the same set?  Because the issue would be that anyone that can
log onto the machine as anyone can become myTeam:myTeam.

We are many teams that can log on several hosts, most of the passwords
are the same between the teams, and there is nothing to dread. But the
security issue is interesting me as a personal view. In that case, the
setgid is not done on a privileged user, so how can others teams
members become myTeam:myTeam ? I agree that they could be free to
handle all the myTeam data on behalf of myTeam user, but how can be
one of us ?

If all users that can log onto the machine are authorized then that is
fine.  There is no remote exploit available.  It is only vulnerable by
an already running user process on the machine.  Then I see no problem
in the case you describe.  That would be okay.

Bob


Thanks for this discussion ;)

Gal'



Reply to: