Issue:
When an scm command is run with a null value for the --config parameter, it changes the permissions of the current working folder ($PWD) and all its contents recursively to 700.
OS: RHEL5.9
SCM Client tools version: version 3.1.300
RTC Repository: 4.0.5
Details:
The permissions of $PWD and its contents before the malformed scm command was run is shown below
13: pmn@rhel-pc /home/pmn/workspaces > ls -ld .
drwxrwxr-x 3 pmn ccusers 4096 May 1 14:29 .
14: pmn@rhel-pc /home/pmn/workspaces >
14: pmn@rhel-pc /home/pmn/workspaces > ls -lart
total 12
drwx--x--x 10 pmn users 4096 Jan 30 14:53 ..
drwxrwxr-x 3 pmn ccusers 4096 May 1 14:29 .
drwxrwxr-x 15 pmn ccusers 4096 May 1 14:31 pmn_release_20140516
15: pmn@rhel-pc /home/pmn/workspaces >
Executed the malformed scm command:
15: pmn@rhel-pc /home/pmn/workspaces > scm --config "" status -C -w -B
16: pmn@rhel-pc /home/pmn/workspaces >
Permission of $PWD and its contents after the malformed command was run is shown below:
16: pmn@rhel-pc /home/pmn/workspaces > ls -ld .
drwx------ 5 pmn ccusers 4096 May 17 15:57 .
17: pmn@rhel-pc /home/pmn/workspaces >
17: pmn@rhel-pc /home/pmn/workspaces > ls -lart
total 28
drwx--x--x 10 pmn users 4096 Jan 30 14:53 ..
drwx------ 15 pmn ccusers 4096 May 1 14:31 pmn_release_20140516
drwxrwxr-x 3 pmn ccusers 4096 May 17 15:57 scratch
-rw-rw-r-- 1 pmn ccusers 5183 May 17 15:57 preferences.properties
drwxrwxr-x 3 pmn ccusers 4096 May 17 15:57 daemons
drwx------ 5 pmn ccusers 4096 May 17 15:57 .
18: pmn@rhel-pc /home/pmn/workspaces >
19: pmn@rhel-pc /home/pmn/workspaces/pmn_release_20140516 > ls -lart
total 60
drwx------ 3 pmn ccusers 4096 May 1 14:29 .metadata
drwx------ 2 pmn ccusers 4096 May 1 14:29 Documents
drwx------ 2 pmn ccusers 4096 May 1 14:29 bin
drwx------ 4 pmn ccusers 4096 May 1 14:29 EAR
drwx------ 3 pmn ccusers 4096 May 1 14:29 Libs
drwx------ 2 pmn ccusers 4096 May 1 14:30 ListenerUtil
drwx------ 2 pmn ccusers 4096 May 1 14:30 WSEAR
drwx------ 2 pmn ccusers 4096 May 1 14:31 WStarget
drwx------ 11 pmn ccusers 4096 May 1 14:31 Web
drwx------ 2 pmn ccusers 4096 May 1 14:31 WebServices
drwx------ 2 pmn ccusers 4096 May 1 14:31 databases
drwx------ 2 pmn ccusers 4096 May 1 14:31 target
drwx------ 15 pmn ccusers 4096 May 1 14:31 .
drwx------ 10 pmn ccusers 4096 May 1 14:31 .jazz5
drwx------ 5 pmn ccusers 4096 May 17 15:57 ..
20: pmn@rhel-pc /home/pmn/workspaces/pmn_release_20140516 >
Note the change in permission of all folders to 700. This IMHO is both undesirable and unexpected.
1: pmn@rhel-pc /home/pmn/workspaces > uname -a
Linux rhel-pc 2.6.18-348.6.1.el5 #1 SMP Fri Apr 26 09:22:54 EDT 2013 i686 i686 i386 GNU/Linux
2: pmn@rhel-pc /home/pmn/workspaces >
2: pmn@rhel-pc /home/pmn/workspaces > scm version
com.ibm.team.filesystem.cli.core, version 3.1.300.v20130426_0115
Provides Subcommands:
daemon, daemon/start, daemon/stop, daemon/deregister, daemon/register
com.ibm.team.filesystem.cli.client, version 3.1.300.v20130426_0115
Provides Subcommands:
load, login, logout, create, create/workspace, create/baseline,
create/changeset, create/snapshot, create/component, create/loadrules,
create/stream, changeset, changeset/comment, changeset/complete,
changeset/current, changeset/relocate, changeset/associate,
changeset/disassociate, changeset/suspend, changeset/resume,
changeset/discard, changeset/extract, changeset/locate, change-target,
change-target/workspace, change-target/component,
change-target/unset-workspace, list, list/workspaces, list/projectareas,
list/teamareas, list/streams, list/components, list/remotefiles,
list/credentials, list/daemons, list/snapshots, list/locks, list/properties,
list/changes, list/users, list/baselines, list/changesets, list/states,
list/flowtargets, list/preferences, checkin, accept, deliver, status,
validate, conflicts, resolve, move, lastmod, share, discard, undo, compare,
history, diff, repair, workspace, workspace/change-target,
workspace/component, workspace/unset, workspace/add-components,
workspace/remove-components, workspace/replace-components, workspace/delete,
workspace/unload, workspace/propertylist, workspace/propertyget,
workspace/propertyset, workspace/add-flowtargets,
workspace/remove-flowtargets, workspace/flowtarget, component,
component/propertylist, component/propertyget, component/propertyset,
baseline, baseline/propertylist, baseline/propertyget, baseline/propertyset,
property, property/list, property/get, property/set, property/remove, lock,
lock/list, lock/acquire, lock/release, annotate, snapshot, snapshot/promote,
snapshot/propertylist, snapshot/propertyget, snapshot/propertyset, refresh,
users, users/set, delete, delete/state-content, changeaccess, extract,
extract/file, debug, debug/fetch, debug/fetch/changeset,
debug/fetch/component, debug/fetch/workspace, debug/fetch/item,
debug/fetch/uri, preference, preference/get, preference/set
com.ibm.team.rtc.cli.infrastructure, version 3.1.300.v20130425_0448
Provides Subcommands:
help, version
com.ibm.team.filesystem.cli.tools, version 3.1.300.v20130503_0103
Provides Subcommands:
tools.verify, tools.validate, tools.echo.stdin, tools.metronome,
tools.pkgtest, tools.configvalue, tools.log, tools.generatehelp, tools.dump,
tools.dump/postprocess
3: pmn@rhel-pc /home/pmn/workspaces >
Comments
Setting the --config option to empty does not make sense. What is your intention behind setting it to empty? Ideally it should have thrown an error but looks like it is picking up the current directory as the configuration location.
Hi Shashikant,
I use wrappers around scm commands and some of these run scm with the --config option. A null --config value had been passed to these scm commands via the script in certain scenarios (obviously a bug in the wrapper script - which has since been fixed) which ended up corrupting the permissions of a whole bunch of folders. To make matters worse, the corruption of the folder permissions was noticed many days later during which time a multitude of commands had been run on the affected host by several users -- to connect the permission problem to a malformed scm command that was issued several days earlier was near impossible as end-users are not aware of how or why scm changes folder permissions. I'm sure there are people out there who write wrappers around the scm command who might potentially face this same issue. I feel this issue warrants a fix - one that either prohibits a null --config value or at least issues a warning.