It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×1,201

question asked: Oct 25 '12, 9:31 p.m.
question was seen: 4,740 times
last updated: Oct 31 '12, 8:47 a.m.

Related questions

RTC 4.0 regression? how to set group/other executable permissions?

0
Paul Smith (26●1●2●2) | asked Oct 25 '12, 9:31 p.m.
retagged Oct 26 '12, 1:32 a.m. by Sridevi Sangaiah (591●7●9)
 I have a number of files that need to be executable in my repository.  They all have the "Executable" property set on them in RTC.  In RTC 3.x when I loaded a workspace, they had executable set on all three user, group, and other (0755, or rwxr-xr-x).

Now I've had to upgrade to RTC 4.0.0.1, and when I load the same workspaces the executable bit is only set on the user (0744, or rwxr--r--).

Of course, I have the same umask as I had before (0022)

This is a big problem for us as we MUST have group and other (in particular) execute bits set.

Am I missing something, or is this a bug in RTC 4.0.0.1?

Thx!
Comments
Paul Smith commented Oct 25 '12, 9:35 p.m.

Just in case it's not clear, I'm using RTC on GNU/Linux.  Cheers! 

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Tim Mok (6.6k●3●8) | answered Oct 30 '12, 5:08 p.m.
JAZZ DEVELOPER
Jazz SCM doesn't support anything more than the user's execute bit so I'm not sure of the behaviour that you had with 3.x. I suggest opening an enhancement for support to set the execute bit for group and other. Although, there are concerns about exposing permissions for users not intended when the bits were set on another machine.

UNIX File Permissions Aren't Maintained After scm load... (161875)
Comments
Paul Smith commented Oct 30 '12, 6:20 p.m.

Hi Tim.  Thanks for the response.  I don't know what to tell you about 3.x: even now if I use my 3.x client to load my workspace all my executable files have all executable bits set.  If I use my 4.0.0.1 client to load my workspace, it has only the user execute bit set.

This is just a bug.  If the concern were really about "exposing permissions", then the group and other "read" permissions would be disabled.  It makes zero sense to allow read but not execute, from an exposure point of view.  Someone just has to copy the file somewhere else and make it executable.

The only non-broken way to make this work is have default permissions of 0666 if the executable attribute is not set, or 0777 if the executable attribute is set, and let the user's umask handle the details.  That's the way UNIX was designed to work and it's worked fine for 40+ years; it's silly for an SCM tool to try to change that.  If users don't want to allow this that should be their choice, by setting umask.

Tim Mok commented Oct 31 '12, 8:47 a.m.
JAZZ DEVELOPER

I've tested on Ubuntu 12.04 and Linux Mint 13 using RTC 3.0.1.4. Ubuntu seems to preserve the execute bits as you see it when I load. Mint does not preserve the execute bits. I'm not sure about the differences and my umask is set to 0022 on both. RTC 4.0 seems to exhibit the behaviour you've described on both Ubuntu and Mint.

I think this does warrant a work item so please open one. It is odd that it has changed between the two versions. It's possible that I just couldn't find the work item that explains this behaviour or it's unexpected behaviour due to some other changes.

As for the umask, there is a work item to respect the setting: We should respect the umask for the user's execute bit (205284). Please add your support to it.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.