new directory permissions

When a user creates a directory, they need to be able to set permissions on it. This should be possible through the TeamSite UI since we don't want users mapping to the virtual device.

I would also like to have the system create the corresponding directories within the corresponding /templatedata/category/type/data directory (or directories if multiple templates write files to a single output directory), and set the permissions on that/those directory/directories as well.

Anyone doing anything like this?

Find more posts tagged with

Comments

Migrateduser

What types of permissions do the users need to set?

One thing I have done before is set an iwat trigger on CreateFSE. The trigger checks to see if the file is a directory, and if it is it can set the appropriate permissions, and based on that file path create a new directory.

Alternatively, you could create a TeamSite file menu option that prompts the user for the new directory name and permissions and then creates the directory and its related directory. This would, however, be slightly clumsy to use in templating. However, a simple callout on the DCT could be added to enable this. If you are using TeamSite 5.5.2, you could even use FormAPI to set a trigger on the save-as event to call your special directory creation program.

Migrateduser

It's more Windows ACL than permissions. Basically they need to be able to say who can create files in that directory (select groups). I have a similar issue for who can access the content after it's deployed that could use the same UI.

I would prefer to avoid a custom solution. I can do the trigger, but I have to give the user a UI so they can change it, and I don't want them mapping a drive or using UNC. Doesn't everyone have this problem? How do users set permissions on existing directories? Shouldn't a UI for this exist in the product?

Migrateduser

Why do the users need to set such granular permissions? Will this happen only during initial rollout, or regularly?

The iwserver mount IS the current TeamSite interface for setting granular permissions. This allows the maximum flexibility in setting and modifying file level permissions. For users where this is not appropriate, a custom solution will almost surely be required.

Migrateduser

This seems like a pretty standard requirement for Intranet projects.

Is there any way to let users change permissions through the filesystem but not edit content? Because using the file system interface breaks templating and locking, right?

Adam Stoller

I'm a bit confused here - are you talking about setting permissions on directories when they are created - or when they are submitted?

The latter can be handled OOTB via submit.cfg.
The former can probably best be handled via custom menu items/CGI's.

If you set the permissions via the filesystem *before* submitting, it shouldn't break locks - and it should only affect templating if the access rights are such that it prevents a user from reading/writing into it.

Are these permissions for the *development* environment or for the *production* environment? For the latter - OpenDeploy provides options that can be used to set access rights on files and/or directories when they are deployed.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

I need to set permissions when the directories are created to limit who can create files in those directories.

I can't give users control of submit.cfg - even I don't want to maintain submit.cfg. The rules are not set ahead of time so that they could be configured by an admin even with submit.cfg, and if they could I would probably do it with a config file in some other format and a custom menu item to create the directory.

It's not setting permissions that breaks the locks, it's that if users have access to the share they can edit templated and locked files with client applications that would defeat templating and locking. Anyway the permissions on the directory in /templatedata are more important (since workflow always writes the files to the output directory as SYSTEM, so permissions on the output directories are not as critical) and I would never ask a user to navigate that thing.

I need to control permissions on both the TeamSite side and the webserver. But again, the rules cannot be coded - they users have to be able to select what groups can edit files in TeamSite and what groups can view them on the webserver.

Adam Stoller

Okay - then I guess you're looking at a custom menu item that interacts with the user - probably run as root / Administrator (or SYSTEM) - that prompts explicitly for the mode bits to be set (and probably verifies them, so as to prevent trojan horses).

At one point a while ago - there was talk about adding some kind of administrative interface like this to TeamSite. I think the issues of security and the myraid number of possible ways in which any given OS might be configured (NIS, YP, LDAP, AD, NT, PAM, etc) caused this to be relegated to a kind of "nice idea, but ..." category.

If you'd like to strike up the cause again, feel free to contact Interwoven Support to open a Feature Request - but I think if anything, the number of variables has grown since this was first brought up, so I'm not sure if it makes sense for Interwoven to try to productize it....

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Thanks. I don't see much point in filing yet another feature request though.

I am more interested in hearing what other people are doing on this issue - does everyone really have a TeamSite admin step in every time there is a new directory or a user wants to control permissions, do you give users access to the share or have you built something custom?

Migrateduser

I have handled this issue by setting up a custom configuration file and a setacls program that would go through directory structures listed in the config and recursively change permissions for certain groups. Then I just add users to the appropriate group(s).

For example, I've got a directory tree like this:

Root -
..........|--Department 1
............|--Sub Department 1
............|--Sub Department 2
..........|-- Department 2

I'd setup my config so that group1 has access to department 1 files/folders/subfolders. group 2 has access to department 2 files/folders/subfolders. group 3 has access to sub department 1, and group 4 has access to sub department 2.

Then just put the appropriate users in the appropriate OS groups.

On NT you can use a program called xcacls.exe (from the resource kit) to set permissions from the command line. On Solaris, it's built in to the OS (chmod/chown/chgrp).

- Jason

Migrateduser

Are you saying that your group names match your directory names? Or do you know the directory names before the configuration script runs? Either of those won't work for me - it really has to be dynamic. Or do you mean something else?

At this point I imagine I have to build a custom menu item that does all the work.

Thanks,

-John