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

TS Samba & Roles

crusader

I've a question about using the Samba that is shipped with TeamSite, in relation to the roles .uid files. We've found a problem whereby someone was unable to edit files via Samba, and the reason appeared to be he wasn't in a roles file (which is fine and secure, our primary concern, if that is the reason). Also we had a situation where another user, who had never logged into the "proper" TeamSite GUI and thus never validated his password according to our routine, made his debut in TeamSite via the Samba mount and was able to navigate, create files etc, but not edit - this person was in a roles file. As soon as he validated his Unix password (he still being in the roles file), he was able to eidt via Samba.
So I'm wondering about the relationship between TeamSite Samba and the TS roles .uid files. Is it necessary to have users in the roles files for them to edit via Samba? Also, as security, and procedures for same, is our main concern at the moment, does anyone have some comments on TS Samba versus TS GUI regarding security concerns? I'm considering whether to disallow Samba access as it seems to introduce extra problems. Thanks.

Find more posts tagged with

Comments

Agamemnon

Hi,

Teamsite user can use Samba to edit configuration files without Teamsite virtual file system. For instance, iw.cfg... available_templates.cfg, templating.cfg are sometimes so large , that would bring a lot of problems by editing in unix command line.
Decision:
1 ... create the directory /usr/.../samba
2 ... set permissions and mount all neccessary files or directories from 'iw-home' in it
3 ... connect iwserver from Samba/Windows, enter this directory
4 ... open the file in texteditor for editing (Textpad for Windows can save files in Unix-UTF8 mode, but can change permissions after editing)
5 ... save changes, close the editor
6 ... check up permissions to let another user edit this file after you

I do not see any other neccessity of using Samba.
Sorry for my bad english.

AGmm

Migrateduser

Most of our users use Samba to push files to our TeamSite server. None of those users has TeamSite access, meaning they don't have TeamSite logins, and therefore are not in any of the .uid files. All that I have to do to allow a new user to Samba into our TeamSite server is to give them a Unix login to the server and make sure they are a member of the correct group(s) associated with the workarea(s) they will be writing into.

The problems we've had are mainly the group permission thing when the users are in more than the allowable 16 groups. Then we have issues. We also have problems because if the user is a member of more than one group and they push a file to a workarea, the file will end up being group-owned by that user's primary Unix group, which may or may not be the group the workarea is shared with. If it's not, other people will not be able to edit that file. We get around this by setting the gid bit on every workarea and recursive directory. It's a pain but we have no choice.

Also there is no file locking when people use Samba to access files in TeamSite. You basically have free run of a workarea if you are a member of the group it is shared with, regardless of TeamSite locks.

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