Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
S-bit set on the user
LooseCannon
TeamSite 5.5.2 SP3
Solaris
I wrote a little web app that's used to create, edit, manage, and publish content. One of the provided functions is starting a workflow. Being aware that only a 'master', which none of the users are, can run iwjobc I wrapped the cmd in a perl script and set the s-bit on the owner of the script (I'm the owner and have a master role).
The problem is that the sticky bit doesn't seem to have any effect... A user with a non-master role receives an error msg when running the script (I don't).
Following is my perl script that's being invoked:
#--- Begin Script ---#
#!/p01/app/iw/tsite/5.5.2/iw-home/iw-perl/bin/iwperl -w
use TeamSite::Config;
use strict;
my $iwhome = TeamSite::Config::iwgethome();
my $job_spec = "$iwhome/local/config/wft/job-specifications/temp/train18.xml";
my $job_id = `$iwhome/bin/iwjobc -i $job_spec`;
print "ID: $job_id\n";
#--- End Script ---#
The permissions are: -rws--x--x
The script prints out the following when a non-master user executes it:
You must be a master to run iwjobc.
ID:
I thought that setting the s-bit on the owner of a file would cause the file to be executed under the user-ID of the user that owns the file rather than the user that executes the file?
What the heck am I doing wrong?
Find more posts tagged with
Comments
nipper
Stupid question but I have to ask, how are they invoking it ?
p01/app/iw/tsite/5.5.2/iw-home/iw-perl/bin/iwperl blah.ipl ?
sticky bit will not help there.
SHOULD work as blah.ipl
HTH
Andy
LooseCannon
Andy,
I'm executing the script from the cmd line like:
>> /p01/app/iw/tsite/5.5.2/iw-home/iw-perl/bin/iwperl hm-cjob-wrapper.pl
If I don't specify the Perl interpreter I get an Error message:
>> ksh: hm-cjob-wrapper.pl: not found
What effect does the interpreter have on the stick bit?
One correction! Permisions on the script, hm-cjob-wrapper.pl, are -rwsr-xr-x not -rws--x--x
Hemant
you might want to try including the perl path in the shebang line and execute the script just with its name like..
myscript.ipl
nipper
make your fist line:
#!/p01/app/iw/tsite/5.5.2/iw-home/iw-perl/bin/iwperl
and just run it like this:
hm-cjob-wrapper.pl
The sticky bit is used by what is executed, which in your case was perl. If you run the script alone, it should work.
Andy
LooseCannon
Well... actually the first line of the perl script does include the she-bang
#--- Begin Script ---#
#!/p01/app/iw/tsite/5.5.2/iw-home/iw-perl/bin/iwperl -w
use TeamSite::Config;
use strict;
my $iwhome = TeamSite::Config::iwgethome();
my $job_spec = "$iwhome/local/config/wft/job-specifications/temp/train18.xml";
my $job_id = `$iwhome/bin/iwjobc -i $job_spec`;
print "ID: $job_id\n";
#--- End Script ---#
Hemant
remove the following line..
#--- Begin Script ---#
she-bang line needs to be the first line..
nipper
If you cannot just execute the script off the commandline
like
./script.ipl
then something is wrong.
The comments must start at line 2. Besides, who comments perl anyway ? Mine is always self documenting.
LooseCannon
#--- Begin Script ---#
and
#--- End Script ---#
are not in the script... they only exist in my post for identification
Adam Stoller
If I don't specify the Perl interpreter I get an Error message:
>> ksh: hm-cjob-wrapper.pl: not found
This is usually either an indication that you are trying to run the script from someplace that is not on your PATH and without using an explicit path (like
./hm-cjob-wrapper.ipl
) or you have a typo in the sh-bang line such that the actual Perl interpreter cannot be found.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
LooseCannon
This is aggravating...
I thought that wrapping a script around iwjobc and running it as a master user would be easy ;-)
Maybe I need to setup the PATH variable in the user's profile to point to IWHOME/iwperl/bin??
It's late... I'm tired... I'm going home... will continue to dig tomorrow...
Thanks for the advice guys.
skip11
this is NOT a sticky bit, it's suid.
sticky looks like this:
drwxrwxrwt 2 jerry ora 32 Nov 19 10:31 share
RB
LooseCannon
new day...fresh start...got it to work!!
As fish suggested, I was able to run the script explicitly, i.e.,
./hm-cjob-wrapper.ipl
(I feel real stupid... I should have tried this)
But then I received another ERROR MSG:
Insecure $ENV{PATH} while running setuid...
I grabbed the
camel
book and browsed through Chapter 23 and noticed this sentence; "Perl automatically enables taint mode whenever it detects it's program running with differing real and effective user or group IDs."
After setting $ENV{PATH} to an untainted value the script successfully ran.
LooseCannon
thks for correcting my terminology...you're a huge help
strmsrv2.PNG
Migrateduser
You got off easy. If you had passed in parameters to your script, you would have experienced the total "taint" joy. Untainting your code is not fun.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
So far I haven't seen an answer posted to this question:
> What effect does the interpreter have on the stick bit?
>
The set-uid bit has to be on the program being executed to take effect. When you invoke it as:
blah.ipl
... the set-uid bit is taken into account. But when executed as a parameter to another program, the OS would look for a set-uid bit on the $0 item of the command line, in this case 'iwperl' and not consider any set-uid bit on the parameter (your script).
Migrateduser
Right, if you wanted to have the script execute as the same user as whom the sticky bit is set for blah.ipl, consider calling blah.ipl directly, and not
$iwhome/iw-perl/bin/iwperl blah.ipl
Assuming you have the path to iwperl in your #! line, you would call it directly. This would enforce the setuid bit.
Dave
dave@simpleinternet.com
+USA (215) 962-5153