Unix rights are in general set up with the chomd. You can display them with
ls -la
. Thereby the format of the entries is the following order:
Important: If a directory doesn't have thee x its also not readable, because to do so there must be an execution of a command (ls, cp, …) on the directory.
ls -la /home/myuser/test total 10 drwxr-xr-x 3 myuser student 512 2005-02-18 14:29 . drwxr-xr-x 124 myuser student 6656 2005-02-18 14:28 .. drwxr-xr-x 2 myuser student 512 2005-02-18 14:29 somedir -rw-rw-r-- 1 myuser student 0 2005-02-18 14:29 somefile lrwxrwxrwx 1 myuser student 8 2005-02-18 14:29 somelink -> somefile
Here all objects belong to the user myuser and the group student whereby the file somefile and so also the symlink somelink are writeable by every member of the group. Everybody is allowed to read everything, but only if all directories in the directory hierarchy to the current are read- and executable for the user. If you want to restrict these rights for a certain group of users, ACLs come along.
The set up and changing of the rights has the form Who, Withdraw/Give (+/-), Which:
chmod go-r /home/myuser/test/somefile chmod g+w /home/myuser/test/somedir
These commands withdraw the rights for reading on the file somefile for the group and the rest in the first step and in the second step the writing rights for the group on somedir. Rights can be set by the specification of values:
chmod 644 /home/myuser/test/somefile chmod 755 /home/myuser/test/somedir
The commands above set the rights for somefile for the reading/writing of the owner and the reading for everybody else. The values are specified by octal numbers. The order is: owner, group, rest where the values for reading (4), writing (2) and execute (1) add up.
Other then in Windows-system the file is executable precisely when the user has the unix-rights to do so, unattached by the file extension.
Aside from the unix-rights in practice of the pool computers what also matters are the ACLs.
Concerning directories the right to execute means that you are allowed to change directories. In Symlinks (to be created with ln -s) all rights are “set” because all if its rights are deducted from the linked objects.
ACLs
Access Control Lists (ACLs) allow a more fine-granted right assignment then the classical unix-rights. It's e.g. possible to give or withdraw individual users rights for files and directories.
ACLs can be found e.g. as part of Microsofts filesystem NTFS but also in Sparc/Solaris in the form of UFS. The necessary commands there are getfacl and setfacl
For a generell tutorial in ACLs (as well a short tutorial for an introduction in CVS-repositiories like described below) take a look e.g. in the EiSE ACL tutorial. To allow it certain other users the access on the home directory (which is necessary for CSV) you have to do the following steps for every user (“someuser” is the particular user:) and check the outcome at the end using getfacl:
setfacl -m u:someuser:rx ~ setfacl -m u:someuser:rwx ~/myproject getfacl ~
Note: The wave or tilde ~ is a placeholder for your own home directory.
The first command will allow the user “someuser” to enter the home directory the second gives the user writing permission on “myproject”.
If you want that new files and directories also have the rights of their parent directory you have to use the setfacl command again with some little modification:
With
setfacl -d u:someuser project
the rights which were granted via ACL for some user on project will be deleted.
Files or directories with ACL-entries will be marked with ls -al marked with +:
-rw-rw-r--+ 1 myself mygroup [...] project -rw-r----- 1 myself mygroup [...] some_private_stuff
If you want to set up the rights for newly created files in a directory (default permissions) you can do it that way (exclusive access for the owner):
setfacl -d -m u:someuser:rwx ~/myproject
For more questions use
man setfacl
.
The concurrent version system (CVS) makes it possible to work together with several people on one project. The check-in and check-out process automatically performs a version control, i.e. changes can be tracked and, if necessary, reversed. You can add comments to the check-ins so everybody can see where the changes are.
The RBG/ISP offers a SVN/GIT server for students with a RBG/ISP account since august 2011. You can find a short tutorial on the page svn-git.
On the pool-computer the set up has two parts: First you have to grant every project-member access on the home-directory using ACLs, which is described above. This is necessary due to the fact that the unix rights allocation demands that all directories in the directory hierarchy be readable and executable up to the current one.
To be able to use CVS you need a so called repository. First of all this is a normal directory which is created empty using mkdir. ACLs can be used to make this accessible for reading and writing for every project-member (look above - replace ~ with the path to the empty directory.
After that you will be able to initialize the directory as CVS-repository:
mkdir /home/myuser/cvsrep setfacl -R -m u:someuser:rwx /home/myuser/cvsrep cvs -d /home/myuser/cvsrep init
The outcome is a subdirectory CVSROOT which contains the meta data. The repository is set up and usable. If you've set up the repository in the home-directory this will have effects on the quota.
For the external access it's a good idea to use SSH.
Under the EiSE CVS tutorial you will find a short description for the set up of CVS with Eclipse.
If you're using Unix/Lunix there are a lot of different clients for the access to CVS.
If you're using Windows there is on the one side WinCVS as graphical interface and on the other side you can use the extension for the context-menu like TortoiseCVS.
For the access via command line please take a look at the tutorial for CVS. Most alternative interfaces use often the same terms so it's helpful to read these tutorials.
Subversion
Aside to CVS it's also possible to use subversions for the version-management. The handling is quite similar to CVS on purpose; e.g. are the commands for the checkin and checkout here also commit and checkout.
Subversion-repositories can use different database-backends. By default the version 1.2 FSFS is used (before BerkeleyDB):
svnadmin create repository_name
During the creating it's possible to specify the backend explicitly (fsfs or bdb):
svnadmin create --fs-type bdb repository_name
The BerkeleyDB does not work in NFS-mounted directories like the user home-directory.
To make the project accessible for other persons, e.g. project-members, you have to grant these rights via ACLs (like above):
setfacl -R -m u:someuser:rwx repository_name
Under Debian the recursive allocation of rights via ACL works for the sub-directories this way:
find Verzeichnis/ -exec setfacl -R -m u:someuser:rwx {} \;
Like in the case of the CVS the repository in the home-directory has the same effect on the quota.
Using the local version of checking out:
mkdir trunk branches tags svn add trunk branches tags svn commit -m "initial checkin"
First you have to make sure for every person who is allowed to access that the program svnserve - which is installed in /usr/bin/ - can be found by the ssh. For that you have to create or modify the file .bashrc (if the login-shell is bash); do to so the following line is relevant:
export PATH="/usr/bin:$PATH"
After that you can check out:
svn co svn+ssh://user@clientssh1.rbg.informatik.tu-darmstadt.de/home/user/repository_name
(for Checkin etc. it's analog)
Since the access is made via SSH you have to enter your password every time (or you can use public key authentication, which won't be described here).
Beside the access using the command line there is also the graphical client like TortoiseSVN.
If you receive an error message while using the access via ssh, that the svnserver (or other components) can't be found, it will do insert the following line in the file $HOME/.bashrc:
export PATH="/usr/local/bin:$PATH"
You can find another useful tutorial and introduction on the forum of the student representatives of the department for computer science in the section for Eclipse users in the team.