Changing DCR file permissions using system command

I am using Teamsite 6.1 on Solaris and having some difficulty changing the file permissions of selected DCRs using the system command within a perl script.

Specifically:

system("/usr/bin/chgrp tsusers $name");
system("/usr/bin/chmod 777 $name");

where $name is the full file path of the DCR within iwmnt

The result is the file remaining the same without any changes.

The script is being run within Teamsite as the logged in user. So far I have attempted the following:

run as master
ensured the DCR is not locked
run as the the owner of the locked file

Any help or additional things to try would be appreciated

Find more posts tagged with

Comments

nipper

You are attempting to do something Perl is loath to do, execute "harmful" commands with system. Perl includes commands link chmod, unlink (to remove), and chown.

This is due the fact that someone could trick a perl program into running a harmful command. Imagine there is a CGI that takes an email address and runs /bin/mail to send info.

If I put in my email address as me@foo.bar.com ; rm -rf /

and perl ran that in a system call, there could be big troubles.

Use the perl commands chmod and chown

Andy

ISCBorisB

I am using Teamsite 6.1 on Solaris and having some difficulty changing the file permissions of selected DCRs using the system command within a perl script.

Specifically:

system("/usr/bin/chgrp tsusers $name");
system("/usr/bin/chmod 777 $name");

where $name is the full file path of the DCR within iwmnt

The result is the file remaining the same without any changes.

The script is being run within Teamsite as the logged in user. So far I have attempted the following:

run as master
ensured the DCR is not locked
run as the the owner of the locked file

Any help or additional things to try would be appreciated

Do you have *secondary mapping* configured on your Server?
What is your $name format, cached or non-cached mounting?
In other words, is it /imnt/something... or /.iwmnt/something?
You would probably want it non-cached for chmod.

Adam Stoller

I am using Teamsite 6.1 on Solaris and having some difficulty changing the file permissions of selected DCRs using the system command within a perl script.

Specifically:

system("/usr/bin/chgrp tsusers $name");
system("/usr/bin/chmod 777 $name");

Without being able to reproduce the problem (as I don't need to do this - and my code would most likely be different than yours, etc.) I can suggest the following debugging steps:

my $cmd1 = qq(/usr/bin/chgrp 777 $name);
my $cmd2 = qq(/usr/bin/chmod 777 $name);
my $res1 = qx($cmd1 2>&1);
my $res2 = qx($cmd2 2>&1);
warn("uid: $<\neuid: $>\n$cmd1: $res1$cmd2: $res2);

The first two pieces of information will confirm who the commands are being run by. The next two lines will show the actual command run - followed by any output that might have been generated when it was run.

Hopefully that will help you figure out how to fix your issues.

Note: While I agree with Nipper about using the built-in chown/chmod functions - it's mostly for efficiency. The issue about running harmful commands through scripts is a coding / design issue not a perl issue as perl doesn't care what you put into the system() or qx() calls ... unless it's running in "taint" mode.

nipper

Note: While I agree with Nipper about using the built-in chown/chmod functions - it's mostly for efficiency. The issue about running harmful commands through scripts is a coding / design issue not a perl issue as perl doesn't care what you put into the system() or qx() calls ... unless it's running in "taint" mode.

That is strange. I noticed that I could not use rm (and not in a taint mode scenerio) but I could use unlink. I will have to play with it again. I also just use the built in functions for ease.

Andy

Adam Stoller

That is strange. I noticed that I could not use rm (and not in a taint mode scenerio) but I could use unlink. I will have to play with it again. I also just use the built in functions for ease.

Andy

It's possible you couldn't use 'rm' but might have been able to use '/bin/rm' or '/usr/bin/rm' ... this might be the case if there is no PATH environment inherited in the shell process that was spawned (like within an DCT inline script).

Or perhaps you forgot that you were working on windows? ;-)

Note - I'd still prefer to use unlink() regardless of whether 'rm' worked ...

Migrateduser

Thanks all for your promp replies.

I have tried using the perl command chmod and chown as suggested, but this didn't work either; as far as I can see the files remain unchaged.

for the record I do not have secondary mapping on (in iw.cfg map_secondary_to_primary_gid=no), and I believe I am using cached mounting as my path reference is /opt/iwmnt/default/main/.../Article/data/001/2/1261

Possibly this is the reason why chmod/chown was not working.

However, ghoti's debugging steps proved very useful:

Results:

CMD1: /usr/bin/chgrp aceditor /opt/iwmnt/default/main/.../Article/data/001/2/1261
CMD2 /usr/bin/chmod 777 /opt/iwmnt/default/main/.../Article/data/001/2/1261

RES1 chgrp: /opt/iwmnt/default/main/.../Article/data/001/2/1261: Not owner
RES2 chmod: WARNING: can't change

which indicated the chgrp couldn't run as it was not being run as the owner.

So when I asked the owner to try it worked ! Smiley Happy

But I need this script to run on files where the logged in user may not be the owner, so I attempted to run:

my $cmd3 = qq(/usr/bin/chown [logged in user here] $name);

but this also returns 'not owner' , most likely for the same reasons above.

Is there another way to change the owner of the file whilst running as a different logged in user?

Thanks for your continued help on this

Adam Stoller

...
Is there another way to change the owner of the file whilst running as a different logged in user?

Thanks for your continued help on this

I'm glad the debugging technique worked - though you didn't mention whether the UID ($<) and EUID ($>) verified that the script was being run *as* the logged in user.

That aside - you also haven't mentioned *how* this script is being run

That information could provide some additional avenues to explore for finding a resolution.I believe the TS server is running with a process owner of 'iwui' or 'iwts' in 6.1 and not 'root' (as I believe it did in pre-552 days) - which makes it a bit more difficult to circumvent something like this - but knowing how you are trying to invoke the script still may help.

Migrateduser

yes, sorry for not including that information before.

UID ($<) and EUID ($>) confirm that it is being run as 5061677 which in my case is the logged in user.

The script is being run from a custom menu

Adam Stoller

yes, sorry for not including that information before.

UID ($<) and EUID ($>) confirm that it is being run as 5061677 which in my case is the logged in user.

The script is being run from a custom menu

Are you using the iw_cgi_wrapper.cgi to run your script?
If so - you could try not doing so - but I think it will still fail because I believe then it will be run as "iwts" or "iwui" which is neither the owner nor root and thus will get permission denied too.

Other things you could try (keeping the iw_cgi_wrapper.cgi) are to do something like running iwunlock and iwlock before trying to do the chgrp and chmod - as perhaps TS will reset the owner for you. Or maybe try using iwextattr to set (and clear) a temporary EA on the file first. There might be a few other CLTs that don't really modify the contents of the file but which might be sufficient to change the ownership of the file so that you can then do what you want ... worth a try anyway.