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)
Author + Unlock
herald10
Hi,
I am writing a custom menu item for authors to be able to unlock files. But getting
ERROR:00013: Permission denied .
I have untainted all the variables and setuided the script . Still getting the above error.
Any ideas please
Thanks a lot
-H
Find more posts tagged with
Comments
Migrateduser
Did you setuid the owner of the script to be someone who is a Master and also has write access to the workarea you are trying to unlock the file in?
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
herald10
yeah the owner of the script is root.
-rwsrwxr-x 1 root tsgroup 4540 Oct 8 11:59 author_unlock.cgi
nipper
Just a guess here. But when you implement a custom menu item. TS mimics the user (instead of having
it run by iwui). That MAY be overriding your setuid.
Try this as a test. Write one non-setuid CGI that invokes a second one that is setuid and runs the unlock.
HTH
Andy
Migrateduser
Even more straight-forward, have it write "whoami" output to some temp file.
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
nipper
oh, you always take the easy way,
herald10
I tried both.(Andy's suggestion and Dave's suggestion). Still getting the error. The whoami file has the following permissions.
-rw-r--r-- 1 root tsgroup 8 Oct 8 13:29 whoami.txt
So the script is being run as root. But still getting the error(Permission denied).
Any otherway to accomplish it?
Migrateduser
I remember trying to do this exact thing a couple of years ago --
I understand it would defeat the purpose of ROOT owning the user sticky bit on the script, but what happens if you put the wrapper around it?
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
herald10
I am getting the same error. No change from the last output. whoami.txt has root:tsgroup as the owner.
JonathonG
Just a shot in the dark, but....is root in the master.uid file?
IIRC, it is possible for recent verstions of TS to work without root being in the master.uid file. Of course, I may be mistaken.
Jonathon
Interwoven Developer
Allstate, Inc.
Migrateduser
-rw-r--r-- 1 root tsgroup 8 Oct 8 13:29 whoami.txt
I'm just curious -- were you able to look at (in) the file? I don't know why I didn't notice it before, but if the output of your script, the content of whoami.txt, only said "root", wouldn't it be 5 bytes long, not 8 as your long listing suggests?
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
herald10
yeah root is present in the master.uid file.
JonathonG
Ok...one other shot in the dark...is root in the group for sharing for that workarea? I wouldn't think this would be necessary, but otherwise it sounds like you're doing things right.
Jonathon
Interwoven Developer
Allstate, Inc.
herald10
The file has just the following text.
"Who Am I"
Migrateduser
Okay, sorry -- I was taken too literally :-)
I don't think this is as necessary anymore, but I'm still curious about this -- try deleting the file first.
In the script, I meant for you to execute the command "whoami" and write the output to that file. The "whoami" command just echoes the user id, so the contents of the file might be "root".
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
herald10
Yeah the file just has the word "root" in it. And its size is 5 bytes.
herald10
Actually the root is not a part of tsgroup. So I changed the owner of the script as a master user(member of tsgroup) and tried it again. Still the same behavior.
TCavanaugh
The Unlock operation is not allowed by an Author. You will need to find a way for the Author to initiate an action, which is eventually performed by a different user - one who is an Editor or higher.
We developed a system where actions are added to a queue, and a separate process (a Windows service) removes tasks from the queue and email the results to the user.
-TC
Migrateduser
Are you able to perform this action from the command line as root? Silly question -- I'm sure the answer is yes -- but I'm trying to see all possibilities.
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
herald10
Yeah I can do it from command line as root. Not at all a problem. But heres something I did. Instead of Unlock I called chmod to change permissions on another file. And that worked with out any problem. so the problem seems to be with the CLT(iwunlock). I also tried calling this CLT from a shell script. Something like:
#!/bin/sh
`/iw-home/bin/iwunlock /default/main/My_branch/WORKAREA
/My_wa/filelist.txt`
This returns the same error:
ERROR:00013: Permission denied
Adam Stoller
Authors can unlock files that they themselves have locked.
Authors cannot unlock files that someone else has locked.
You could have your custom menu item determine if the file attempting to be unlocked is locked by someone other than the current user and (a) inform them who the current lock owner is, (b) send email to the current owner requesting that they unlock it, (c) cc the mail to the branch or workarea owner, (d) some combination of the above.
I strongly advise *against* trying to create setuid scripts for this purpose - as setuid scripts are notoriously bad security risks and most sysadmins / IT staff will get significanly **** if they find any on systems for which they are responsible (and in some companies - the person who created it can be fired for violating security regulations!)
If you really need to allow authors to unlock files owned by someone else - then I suggest you create a workflow - and then you can use an externaltask owned by the areaowner to perform the task of unlocking the files attached to the job (or even doing a wide-spread unlock of everything in the workarea -- though I wouldn't generally recommend allowing such actions to be taken by an author)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Frederik
You got a strange situation there! Was it solved already?
BTW, I ran into a similar issue (error message) the other day, making a very similar custom menu item.
What I did was: the CMI calls a first CGI, that just presents the selected files (and some sugar coating, like "locked by" and "lock on date"...). Then there's a "continue" button to a 2nd CGI, which does the unlock.
The 1st CGI is called via the wrapper, which impersonates the acting user. That's TS business that can't be prevented. But I call the 2nd CGI
without
the wrapper. That way, the 2nd CGI runs as iwui, which happens to be master and member of all security groups, eh voila, no more permission worries (for me).
I didn't use any setuid bits or whatever (to be totally honest, havent got a clue of how and why and pro's and con's of those setuid things).
Still, your situation is so very bizarre. Are you sure that root is in the good master.uid file? and that there's been an "iwreset -a" since root was added to that file. BTW, perhaps you should use some brute force like a server reboot. Lots of computer related problems have been solved that way
greets
-Fred
herald10
Ghoti,
Thanks for your detailed response. Your first solution makes perfect sense to me. But we have a requirement where one author needs to unlock files locked by another author. I opened a support case. Support guy says iwunlock is using user id and not effective user ID. Is there anyway to get around that?
Thanks a lot
-H
13adam13
Could you reset the value of the username parameter to be that of someone with permissions?
--Adam Wilson
Senior Programmer
Migrateduser
What about ghoti's suggestion? You could make the workflow mostly transparent to the user by implementing it as a custom menu item. You would check off the file, select the appropriate function from one of the drop-downs, and TS would put it through a speedy workflow, whereas the externaltask that is responsible for unlocking the file is owned by someone with a master role.
Dave
Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K