nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OpenDeploy iwodstart

swong74

Hello,

I have defined a user with privs to only one deployment config under User Access->Deployment BUTnoticed that she was able to run another config that she has no privs to. The owner listed in the View Deployments showed the deployment was successful and owned by her. The only thing I can think of was that it was ran using command line like iwodstart. How do I confirm this and how is it that it is permitted to run that config when the userid is not granted permission to that through the GUI? Isn't there a check against privs? Is this a bug ... I think it is. :-)

Find more posts tagged with

Comments

Migrateduser

The only thing I can think of was that it was ran using command line like iwodstart. How do I confirm this

Ummm, did you ask her?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

There currently are no checks on the commandline (iwodstart). If IW did put that in, it would likely break a whole bunch of workflows.

Andy

swong74

I understand that we should allow for some leeway to workflows. OpenDeploy as it stands runs all deployments as root does it not even though you deploy as yourself (cmd line or web GUI).

My concern is this : if users who have local accounts on boxes wherein we define privs to "limit" their deployments thru the GUI, who's stopping them from launching deployments of others and/or creating workflows that will launch them if they have local accounts on the box. I guess in a perfect world everyone knows what and when deployments are made ... but in an evironment with many developers ... that would be like too many cooks to spoil the pot. What if developerA was in the middle of making corrections and developerB (who by the way was not allowed to use deployconfigA thru GUI) just logged on and ran iwodstart deployconfigA. There has to be some check IMHO.

Migrateduser

OpenDeploy runs as whatever user you tell it to run as. The recommended user to run as is root, but that is not always allowable. We run some of our deployments as a user other than root.

Perhaps you could do something with the permission of the iwodstart executable - make it only group executable and put only the users who might have to use it (in workflows and other scripts) members of that group.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

On Unix, OpenDeploy will run as the user who initiated the command.
On Windows, I believe it actually runs as SYSTEM or some such (maybe that's changed since I've last looked?)

There are, I believe, plans to provide for authentication at the command-line but I'm not sure what the time-frame for it is (based on feature requests that have been filed).

If/when authentication at the command-line exists - you would simply need to make sure that your workflow deployment task owner is an allowed deployer. Since this is more often than not performed from an externaltask, it shouldn't be that difficult. In cases where it is performed from a cgitask it may require ensuring that all intended users of that task have sufficient access to launch the deployment. Of course, it's also possible that there might be provisions for enabling certain deployments from being restricted - and then you could use that option for your workflow-specific deployment configurations ... I don't think anything's been written in stone yet so keep the thread going to thrash out ideas and that will help those making the design decisions...

--fish
(Interwoven Senior Technical Consultant)