File permissions are incorrect after deleting then importing file

TS 672 SP2 / Linux

We use TS groups to secure files/dirs. Problem is, the group is changed to the user's primary group when the file is deleted from the workarea. Then if a file is reimported with the same name the user's primary group is applied instead of the expected TS group.

Scenario:
- Import new file (version 0+) - the file is correctly shared by the TS group
- Submit the file to STAGING (version 1) - the file is correctly shared by the TS group
- Delete the file from the WORKAREA (version 1+) - the file is incorrectly shared by the user's primary Unix group
- Submit the deleted file to STAGING (version 2) - the file is incorrectly shared by the user's primary Unix group
- Reimport the file, using the same filename (version 2+) - the file is incorrectly shared by the user's primary Unix group

So basically if a file/dir is created with a name used from a previously deleted file/dir the sharing group is incorrectly set to the user's Unix primary group.

Using the submit.cfg to modify the permissions isn't an option because some deployments source from the workarea.

Ideas?

Find more posts tagged with

Comments

Adam Stoller

TS 672 SP2 / Linux

We use TS groups to secure files/dirs. Problem is, the group is changed to the user's primary group when the file is deleted from the workarea. Then if a file is reimported with the same name the user's primary group is applied instead of the expected TS group.

Scenario:
- Import new file (version 0+) - the file is correctly shared by the TS group
- Submit the file to STAGING (version 1) - the file is correctly shared by the TS group
- Delete the file from the WORKAREA (version 1+) - the file is incorrectly shared by the user's primary Unix group
- Submit the deleted file to STAGING (version 2) - the file is incorrectly shared by the user's primary Unix group
- Reimport the file, using the same filename (version 2+) - the file is incorrectly shared by the user's primary Unix group

So basically if a file/dir is created with a name used from a previously deleted file/dir the sharing group is incorrectly set to the user's Unix primary group.

Using the submit.cfg to modify the permissions isn't an option because some deployments source from the workarea.

Ideas?

Are you using chmod g+s on your workareas and the directories within? If not - try it.

LooseCannon

Are you using chmod g+s on your workareas and the directories within? If not - try it.

Yep.

workarea_default_perm=2771
file_default_perm=664
directory_default_perm=2775

Adam Stoller

Yep.

workarea_default_perm=2771
file_default_perm=664
directory_default_perm=2775

And if you look at the directories from the file system interface do you actually see those settings as having taken place? (just because you configured it, doesn't mean it did it -- when I worked on Unix I always did it manually)

LooseCannon

And if you look at the directories from the file system interface do you actually see those settings as having taken place? (just because you configured it, doesn't mean it did it -- when I worked on Unix I always did it manually)

The permissions are set correctly on the parent directory. Looks like there's a bug that ignores the directory permissions and instead applies the permissions from the file's last version in the hidden edition.

drwxrwsr-x 2 lid6nl8 iwglobal 512 Feb 9 13:12 resources

Adam Stoller

The permissions are set correctly on the parent directory. Looks like there's a bug that ignores the directory permissions and instead applies the permissions from the file's last version in the hidden edition.

drwxrwsr-x 2 lid6nl8 iwglobal 512 Feb 9 13:12 resources

Hmm - I'd suggest opening a case with Support - though I don't know how quickly it will get responded to, nor whether they'll be able to provide you with a fix or work-around.