I need to give file permissions to a specific users only.
My steps:
Setting up new CC group.
Add new group to the CC profile of people who should access to files.
Add new group to VOB.
Change file protection to new group.
Defined permission 770 to files.
But users still do not have access the files!!!!
what Marc says in more detail is what I was eluding to. If you are looking only via a view using cleartool protect will keep out the regular user.
The vobstorage is still open to hacking.
If you need real protection, you need to put all the files you want protected in a separate vob and have its vobstorage in a separate dir and protect that separate dir so only the group with permissions (and ClearCase itself) can read what is in there
p.s. and make sure that the user you are testing the "has no access" with isn't an element owner
[b]pdhaggerty wrote:[/b]
[quote]You at the least need to have 775 perms[/quote]
I believe it is technically possible to have 0 for world, at least in a standalone setup, with local storage.
One problem is with generating cleartext containers, one with MultiSite, one with backup.
These are different contexts in which one needs access.
In any case, protectvob does not affect the pools.
So, one needs also vob_sidwalk (beware the .identity directory on UNIX!) or fix_prot.
There's a technote on the different tools.
Marc
770 is right. 775 means that others, i.e. the world has read access.
Did you only change permissions for the files or also for the parent directory? The permissions of the parent directory come into play as well.
You will want to change the permissions for the parent directory to 770 and not mix files that need to be locked away with files that need to be readable to the world in the same directory.
And if you need it to be seriously hacker proof, this solution won't hold up as the vob storage is most likely readable. It takes a very determined hacker to find their way through there, but ...
hth
For example:
I have VOB [b]XXX[/b].
VOB ownership:
owner a
group b
VOB include frolder [b]ss[/b] and files: [b]1.txt , 2.txt [/b](permission to files : owner a 707, group b 707 other 000)
User have primary group zz + secondary group b.
I want to allow access to files just to user with b as secondary group.
I am working on Windows.
You at the least need to have 775 perms you may have directory that is not in the group and having zero for other may be an issue. Also what is the current group membership details of the VOB and the user(s). Unix or windows and or inter-opt?
You at the least need to have 775 perms you may have directory that is not in the group and having zero for other may be an issue. Also what is the current group membership details of the VOB and the user(s). Unix or windows and or inter-opt?
For example:
I have VOB [b]XXX[/b].
VOB ownership:
owner a
group b
VOB include frolder [b]ss[/b] and files: [b]1.txt , 2.txt [/b](permission to files : owner a 707, group b 707 other 000)
User have primary group zz + secondary group b.
I want to allow access to files just to user with b as secondary group.
I am working on Windows.
770 is right. 775 means that others, i.e. the world has read access.
Did you only change permissions for the files or also for the parent directory? The permissions of the parent directory come into play as well.
You will want to change the permissions for the parent directory to 770 and not mix files that need to be locked away with files that need to be readable to the world in the same directory.
And if you need it to be seriously hacker proof, this solution won't hold up as the vob storage is most likely readable. It takes a very determined hacker to find their way through there, but ...
hth
[b]pdhaggerty wrote:[/b]
[quote]You at the least need to have 775 perms[/quote]
I believe it is technically possible to have 0 for world, at least in a standalone setup, with local storage.
One problem is with generating cleartext containers, one with MultiSite, one with backup.
These are different contexts in which one needs access.
In any case, protectvob does not affect the pools.
So, one needs also vob_sidwalk (beware the .identity directory on UNIX!) or fix_prot.
There's a technote on the different tools.
Marc
p.s. and make sure that the user you are testing the "has no access" with isn't an element owner
what Marc says in more detail is what I was eluding to. If you are looking only via a view using cleartool protect will keep out the regular user.
The vobstorage is still open to hacking.
If you need real protection, you need to put all the files you want protected in a separate vob and have its vobstorage in a separate dir and protect that separate dir so only the group with permissions (and ClearCase itself) can read what is in there