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; } } }

Best Strategy for group ownership in common workareas

HurricanesFan

Hello,

I'm changing our TeamSite implementation (on Linux) from a policy of individually-owned workareas to 1 common workarea for most users.

In doing so I've come across an issue when files/dirs are created by some users. In our main branch the 'group-for-sharing' is "nlmweb". But when 1 user creates files/dirs they get created with group = her primary group, which isn't nlmweb and other users can not access these. When submitted the group gets changed to nlmweb and then it's OK, but I need to prevent rather than cure.

I think most people employ a common workarea policy, so how do you deal with group ownership of new files/dirs?

Immediate thoughts are:

- setgid (on workarea or root-level directories)

- re-configure all users with multiple groups to have "nlmweb" as their primary group

- any other, hopefully more elegant, solution?

Cheers

Find more posts tagged with

Comments

nipper

I have never really seen this as a problem, but I know Smitty dealt with it a lot a number of years ago.

From what I remember, he used the setuid/gid bit. You should also be able to set a trigger on a CreateFSE and chgrp then

Another idea is a custom menu item for mkdir, which does the mkdir and then chgrp's it. This won't work if you use the filesystem interface, nor if you import a directory structure.

HurricanesFan

Thanks Nipper.

We have a menu item option "Create Page" which brings up a cgi to create both a DCR and page of the same name, so users don't get their hands dirty with "new form entry" etc, so we need to fix at inception.

I've just been trying setgid. For that to work in lower-level directories it would need to be a recursive `chmod -R g+s`, which is a bit ugly given the size of our site (the command is still running...). Is that what others are doing?

Cheers

HurricanesFan

On further thought, the big downside to a recursive setgid is that all the files will show as 'modified' and that is probably a deal-breaker for us.

Unless there are any other options, it's looking like I may have to re-configure users to change their primary group.

I think this issue is probably the one factor in favour of individually-owned workareas versus a common group-owned workarea, nicht wahr?

nipper

Are you concerned about files or directories ? You can use a command like this to setuid only directories

find somepath/ -type d -exec chmod g+s {} \;

nipper

HurricanesFan wrote:
Thanks Nipper.

We have a menu item option "Create Page" which brings up a cgi to create both a DCR and page of the same name, so users don't get their hands dirty with "new form entry" etc, so we need to fix at inception.

I've just been trying setgid. For that to work in lower-level directories it would need to be a recursive `chmod -R g+s`, which is a bit ugly given the size of our site (the command is still running...). Is that what others are doing?

Cheers
PJ

Can you fix it at this point then ? You have a custom menu item that is making the directories, can they be created with the main group ?

HurricanesFan

Nipper,

could add that to the cgi but still would have "New Folder", "New File" etc.

HOWEVER, your suggestion of using find to just setgid on directories looks to be a winner:

./iwcmp /iwmnt/default/main/nlm/STAGING/ /iwmnt/default/main/nlm/WORKAREA/nlmoccstest3/

[nothing]
find /iwmnt/default/main/nlm/WORKAREA/nlmoccstest3/htdocs -type d -exec chmod g+s {} \;
./iwcmp /iwmnt/default/main/nlm/STAGING/ /iwmnt/default/main/nlm/WORKAREA/nlmoccstest3/

[nothing]

So no modified files after that, I was very pleasantly surprised. This may be the best solution.

Will do some more testing, but that may be the answer.

Cheers

Adam Stoller

You don't see any results from iwcmp because directories don't get versioned after the initial creation.

If you were to create a new workarea and populate it from an edition - the directories in that workarea would have the old (non-g+s) permissions; but since you're moving to consolidate workareas instead of create more, this should not be an issue.

nipper

ghoti wrote:
You don't see any results from iwcmp because directories don't get versioned after the initial creation.
If you were to create a new workarea and populate it from an edition - the directories in that workarea would have the old (non-g+s) permissions; but since you're moving to consolidate workareas instead of create more, this should not be an issue.

Which is pretty much moot, since his submit.cfg will change it correctly. The main issue is for directories that have no version yet, which this should take care of.

David Smith

I'm late to the party (story of my life) but I see my name was mentioned, and not in an insulting way, so I was intrigued. What we do, as Andy referenced, is use an event trigger on CreateFSE that essentially uses the iwtestcfg CLT to capture the group and mode permissions for any path based on what submit.cfg would set, and force those permissions on any new file/folder using the iwaccess CLT. If anyone is interested, I might send you the script (it's a ksh script). This works perfectly to keep our files and folders free of the Unix gid nonsense.

HurricanesFan

Hi Smitty,

I would be interested to see the script. How can you send it?

Cheers

David Smith

Doesn't look like I can PM you, so I'll just paste it here - there's nothing really proprietary here. You invoke the event by typing:

iwat CreateFSE /path/to/set-new-file-permissions.sh

You look at your active even trigers with: iwlsat

You probably knew that but anyway, here's the script:

#!/bin/ksh

# This script is now registered with the backing store as an event trigger
# using the CLT:
#
#     iwat CreateFSE /opt/appbin/TShome/custom/triggers/set-new-file-permissions.sh
#
# This is a much preferred method to registering event handlers than using iwlocal.cfg,
# but is not documented as such by Interwoven, unfortunately.  This method of invoking
# an event handler does not use environment variables to pass in the file being created.
# Instead, it uses command line arguments.  These arguments vary depending on the event.
# For the CreateFSE event, the following arguments are passed:
#       Arg 1: current date/time
#       Arg 2: username
#       Arg 3: user's role
#       Arg 4: the event (CreateFSE in this case)
#       Arg 5: vpath to workarea
#       Arg 6: relative path to the file
#
# So the FILE variable in this script should concatenate the 5th and 6th argument.

LOG=/tmp/trigger.log
#IW_FILE is an environment variable set by the trigger
#FILE=${IW_FILE}
FILE=$5$6

#FILE=/iwmnt/default/main/Southwest/Common/WORKAREA/shared/templatedata/advisories/travel_advisory/data/brrr

TSHOME=`cat /etc/defaultiwhome`

GROUP=`${TSHOME}/bin/iwtestcfg ${FILE} | grep "gid=" | sed 's/gid=//g'`
PERMISSION_SET=`${TSHOME}/bin/iwtestcfg ${FILE} | grep "perm=" | sed 's/perm=//g'`

#echo "File:${FILE}  GROUP:${GROUP}  PERMISSION:${PERMISSION_SET}" >> ${LOG}
#echo "GROUP:${GROUP}"
#echo "PERMISSION:${PERMISSION_SET}"
if [[ -n "${GROUP}" ]];
then
#        echo "Setting file ${FILE} to GROUP ${GROUP}" >> ${LOG}
        ${TSHOME}/bin/iwaccess set-group ${FILE} ${GROUP}
fi

if [[ -n "${PERMISSION_SET}" ]];
then
#        echo "Setting file ${FILE} to PERMS ${PERMISSION_SET}" >> ${LOG}
        ${TSHOME}/bin/iwaccess set-unix-permission ${FILE} ${PERMISSION_SET}
fi

HurricanesFan

Got it, thanks Smitty.