Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

 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!

0 votes

Comments

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



One answer

Permanent link
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)

0 votes

Comments

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.

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 log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 1,201

Question asked: Oct 25 '12, 9:31 p.m.

Question was seen: 4,766 times

Last updated: Oct 31 '12, 8:47 a.m.

Confirmation Cancel Confirm