Sticky bit in WA

Hi all -

I am seeing some unusual permissions behavior in a workarea: If the group sticky bit is set on a directory and the directory is group-writable (rws), anyone can write new files to it. However outside of a workarea elsewhere on the file system I don't see this behavior and the user can't write files. I've played around with this both on the Solaris OS and through the GUI and keep getting the same behavior. Does anyone have any insight on this? Thanks!

Brad

Find more posts tagged with

Comments

Migrateduser

I use the setgid bit on all of my workareas and only the people in the group the workarea is shared with can write into those directories.

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

bradkagawa

Then does that mean that the workarea permissions have an affect on the directories under it? That users CAN write to a directory whose group they do not belong to if it is set to 775 g+s as long as they belong to the workarea group?

Brad

Migrateduser

No it doesn't mean that. I force all my directories underneath a workarea to be group-owned by the same group the workarea is shared with. That's just the way we do it here. I also set the gid bit for every directory underneath the workarea. I am certain that only those who are members of that group can write into those areas with 775 as the permission.

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

bradkagawa

It doesn't make sense to me, but this is the behavior that I am seeing: if a user is NOT in a group they can still write to a directory that is owned by that group is permissions are set to 775 g+s. I wasn't sure if this was for a specific reason.

Migrateduser

You should have your Unix sys admin take a look at it.

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

Migrateduser

Is this the case only when a group is 775 g+s? If a dir is just 775, does this still happen?

Also, what is the group of the workarea root set to. Are these users in the same group that the root of the workarea is set to? This *might* be something that setting "mask_workarea_access=no" might fix.

>>>from the 5.02 release notes>>>
Currently, the workarea root file system permissions override any subdirectory permissions. In some cases, this is not the desired behavior. A new iw.cfg parameter has been introduced that allows this behavior to be changed. By default, the mask_workarea_access flag is set to yes. This setting allows the system to behave as it always has. However, if you want to set different permissions on subdirectories within your workarea, but disable access to workarea root directory, set the mask_workarea_access flag to no in the iwserver section of iw.cfg. In this case, permissions on the workarea root directory affect only this directory instead of the whole tree.
<<<

--
Jed Michnowicz
Interwoven Technical Consultant