Hi to all

I'm having the following problem with my redhat 3 (yes, there are still somme around:-)
I've already search the forum and googled about it, but without success.

I have a folder, belonging to group A
some users of group A can write in the folder, some other not.

the folder privileges are 775

What must I verify further more than groups belongings and folder permissions?
we are 4 techs here working on it, but no one is really a linux specialists.

thanks in advance

I believe that you need to make the folder privileges 777. I don't know whether you know this but the privileges 777 means that the owner (first 7) the people in the same group as the owner (second 7) and anybody else (the third 7) all can modify files in that folder. If you want to restrict the modification of files in that folder to the owner and the people in the same group as the owner then 774 or 775 will do. It just means that anyone who wants to modify a file in that folder will have to be put in the same group as the owner. Either see your system administrator or if you are the system administrator, add the person the the owners group in /etc/group.

hi

thanks for your reply.
But the point is, that several users in group A can write in the folder belonging to group A, but other users, also in group A cannot write and face a permission denied.

I'm getting crazy about this.
I've been suggested to check out the "syncronisation" between the password and groups files, and the shadow password. Either I'm not sure about this, I will have a look anyway.

One info more, read access seem ok for all users of group A

The perms groups are

u = user/owner
g = group
o = other/the world

each of which can be any combo of rwx (read/write/search for dir).
You don't want to open up that dir to the world.
Start by finding out what the current situation is ie

1. ls -l on dir
2. check /etc/group to see who is in the dir's 'owning' group
3. check for ACLs - http://linux.die.net/man/1/getfacl

For a simple situation, you'd have

drwxrwx--- user1 group1

on the dir and everybody in group1 (doesn't have to be primary group).
You might want to force all files to be owned by the dir group eg

chmod g+s dirname
http://linux.die.net/man/1/chmod

For more complex situations, you may want to add ACLs, although it can get fiddly if you start doing that a lot.

HTH

here a little more explanations:

- here the folder I'm in:
yull@rotor:~/test$ ls -al
total 12
drwxr-xr-x 3 yull users 4096 Sep 2 16:51 .
drwx------ 5 yull users 4096 Sep 2 16:51 ..
drwxrwxr-x 2 apache groupA 4096 Sep 2 16:53 proj

- here my groups:
yull@rotor:~/test$ groups yull
yull: users groupA

- here I try to write in the folder 'proj', owned by groupA, wich I belong to, and wich has write access:
yull@rotor:~/test$ touch proj/test.txt
touch: creating `proj/test.txt': Permission denied

WTF!!!!!


thanks a lot to all for your time

Which RedHat 3 are you talking about? A version from somewhere in the 90's (not sure if a version 3 existed) or RHEL?

rhel (enterprise)

Not always, but usually when some people need write access to the same files, it's a sign that version control system can (should ?) be used instead.

Could you explain what is this folder for and why four people need write access to it ?

hi

indeed the problem was raised by a problem with our svn install.

But I insist, I'm able to reproduce the problem on the file system, locally, into my homedir, without using nothing else than my command line ssh connection

we noticed also that if we use a group that is higher positioned in the /etc/groups file, we don't face the problem any more.
Could it be possible there is a limitation to the number of groups in /etc/groups file?

SVN server should be owner of the repository only server (== one UID) should be allowed to read/write repository.

So where your problem come from ?

You may need the newgrp cmd
http://linux.die.net/man/1/newgrp
http://www.yolinux.com/TUTORIALS/Lin...ingGroups.html

hi to all

here we go a little further:
It looks like we had two problems mixed:
- we fixed the gaps between passwd, groups, shadow and gshadow file using the cleaning binaries available.
- we remain with security problem on our nas: after removing a group from a user, doing a logoff/login to activate those changes to the user, the user kept write access rights to the folder, even if he shouldn't. It appears this is linked to a 16 groups limitation of sys-auth on nfs mounted drives.

we're looking to mount our drives on nfs4, or something else.