File Permissions

I created a branch called External using the user administrator, which is in the masters’ role file.

I created 3 workareas in that branch called
Wa1
Wa2
Wa3

Owners are editor1 editor2 and editor 3 respectively, which are in the editors’ roles file

In the editors1 wa though the IFS I copied over a bunch of files and directories and then submitted them to staging.

In the editores2 wa I did a get latest.

All the files and dirs in the editors2 wa have [N/A] next to them.

I know I can manually go in through the IFS and change the permissions.

I though that once you owned a wa any files or dirs that you create, import and get latest on should automatically give you access to these files. I own that directory.

Can some one explain this to me?

The Professor-

Find more posts tagged with

Comments

nipper

Not really. The workarea provides a place to get access, still underneath Unix (or Window) users, groups and permissions dictate individual access. You can easily
screw yourself up by having incorrect group or bad umask
(unix to set file permissions)

The workarea really doesn't effect file access, nor should it. You may want part of a branch not accessible to specific users or groups,

That is why submit.cfg is so important.

Andy

Migrateduser

The workarea really doesn't effect file access, nor should it.

I disagree. I think it would be really nice if I had the option - note I said option - of setting TeamSite workareas up so that it would always force group ownership of any file in that workarea to be owned by the group the workarea is shared with. Because a user can be a member of many Unix groups, but can have only one primary group, the group ownership of files gets screwed up all the time in my workareas. I have to play all kinds of games with the setgid bits of every directory in every workarea. It's a pain for me to administer this. If TeamSite simply did it for me, I would be a much happier administrator. I realize that not everyone would want that feature, which is why I would like it to be an option I can choose to turn on or off.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

Oooooh, a political discussion. I love it. :-)

> Because a user can be a member of many Unix groups, but
>can have only one primary group, the group ownership of
>files gets screwed up all the time in my workareas.

Since you have been working with TS for a long time, I am
assuming that submit.cfg will not take care of this , though I
thought it would/should

What am I missing ?

Also, I am skeptical with your proposed enhancement, esp in a large environment where too many hands are in the pot (Workarea) and the I would not want the group files changing.

Andy

Migrateduser

OK, here is our setup, and that may help clear things up. We have no users that work (edit/create) files within TeamSite. Everyone works from their own PC/Mac and FTP's or Samba's their work over to the TeamSite server into a workarea. Because of this, their files are assigned the group ownership matching their primary group (not necessarily the same group that the workarea is shared with, but they are a member of that group as well). Then if anyone else (who is also a member of the group the workarea is shared with and is not a member of the other person's primary group) tries to put a modified version of that same file into the workarea, they get a permission problem. Headache for me. If TeamSite simply assigned the group ownership of the files landing in the workarea (whether they got there via FTP, Samba, or magic) to the group the workarea is set to be shared with, life would be grand.

Like I said, this would have to be a config option, perhapes on a workarea by workarea basis that I could set up and choose to use or not. The default would be to not force any group ownership. I just would like to have the option. Options are good.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

Hmmm, I think I get it. This is a problem before someone submits the change, thus submit.cfg does not get invoked.

So you want a filesystem trigger, something that can be invoked on certain filesystem command (fopen() -> chgrp to newgroup)

One thing that has been asked a bunch of times is the ability to trap on certain FS events. (common request, somebody drops a file into a certain dir, invoke a WF).

Now, how to do that without **** up performance is the key. Also is engineerings problem (if they ever do it).

Another thig that would help (and be significantly easier) would be if you could configure launchpad to run as a selectable group. (that is if your uses use launchpad)

Andy

ProfessorX

So let me get this strait.

I need to set the permissions in the submit.cfg file to allow...editor1, editor2 and editor3 to have RW access to the files...

So if a new user/wa is created I would then have to add them to submit.cfg?

Seems like extra work and processing is going on.

Sake of argument we are on WIN2K box 5.5.2

The Professor-

Migrateduser

I'm not a big OS expert, so figuring out something on my own using the OS isn't likely and my Sys Admin help is very limited. I did manage to stick a finger in the leak by creating a hack that wakes up every night and checks to see if anyone had created a new branch that day and if so, update submit.cfg and parse through all the subdirectories in the workarea and set the gid bit. I just think TeamSite could really easily manage that for me. It controls the backing store after all. Oh well...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

No

Submit.cfg will define how the permissions get set once the files get placed into Staging.

So I am joe user, group whatever, I import a file blah, with only myself as writable. submit.cfg says, for this branch, directory (regex in general), blah is to be have the owner be ThisProj and ProjGroup as the group. At that time, the permissions are set to allow group write access.

The only constraint is that I (joe user) needs to be part of the ProjGroup group to work on the file.

Unix has umask (I do not know what the NT equiv is) that defines, when joe creates a new file, the permissions are X. Submit.cfg makes the user, group and permissions all (reasonably) consistant.

HTH

Andy

nipper

forgot to add this. submit.cfg should not be user specific, (usually) only group specific. So when I set up a new branch, or task that is specific to a certain group of people, then I would modify submit.cfg

It is pretty straightforward, no matter how badly I explain it.

Andy

ProfessorX

IN short then nipper....

When a new user gets added to TS and a new WA is created for him...as long as the submit.cfg file is setup correcctlly just add that user to the group correct?

The Professor-

nipper

Yup, bag users, define access by groups

Andy

ToriC

I was just looking into 5.5.2 for this issue and found the workarea_default_perm option in iw.cfg to have new or edited files set the permissions to the group of the Workarea and not the user. Does this resolve the issue you presented without need the submit filter? See KB 49835

Migrateduser

Wow, excellent call. I will try that and see if it works. Thanks for the pointer to that KB article. I would never have found that.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

nipper

In reading the article, it does nto replace the submit filter, rather it automatically set the stick group bit on (or permissions in general) for all workareas.

Definately a nice feature, esp since it helps when you are creating new WAs. Which in turn makes it easier ti import new files.

This should cover 90% or so of the problem. However there will be cases when a file is copied over an existing file (I think will inherit the source not the destination, Dave can answer that) or if someone changes the permissions of a file (I work on Unix) so this is an issue.

This will make my submit.cfg much more simple, but I also need to have certain directories accessable by different groups (within the same branch) submit.cfg is the only thing that will help there.

Andy

Migrateduser

I'm just hoping that the iw.cfg solution will take care of the case where someone creates a new branch/workarea and then loads it up by FTPing all the files over from a remote server. If the iw.cfg permissions are maintained on all the FTP'd files and directories, then that makes my life so much easier. I'm not going to test this (I'll just let life go on and see if it works), but I will post if I find that it is not working the way I hope it does.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

ProfessorX

This is would work for Unix only?

The Professor-