Welcome guest

ACL Rights

Eos/Unity uses the Andrew File System (AFS) to control the many different servers and the files that are located on them. It also handles access rights and security for the system. AFS is very complex, but using some of its simple commands to set access to your account is not very hard.

The files in your home directory of your account are, by default, only visible and useable to two people: you and the administrator. In reality, the administrator is a group of people who all have administrator access for security and maintenance purposes. The administrators will not look at or in any way "mess" with your files unless you have knowledge of it, and only then because there may be some problem with your account. So for all practical purposes, you are the only one who has access to your account.

The reason that only you have access to your account is the same reason that only you have access to your bank account, or your mail box. You generally don't want other people to "mess" with your "stuff." But there are times that it would be convenient to allow other people limited access to your account. For example, if you were in a class and were working on a project with a partner you might want to have a directory in your account that both of you could access.  You can change the ACL (Access Control List) rights to a directory that you "own" (in your account space) to allow other people to access it. However, there are a few things you should be aware of:

  1. Policy regarding electronic cheating:

    The files in your account are your property. Many of these files may be related to academic work you've done at this university. As such, if work you have done is copied by other people and used by them, it could be construed as cheating. Guilt by negligence does not necessarily protect you as it is often very hard to determine the author of the original work. Therefore, it is your responsibility to manage your account responsibly. It is okay to share resources with partners for group assignments if your teacher allows it, but it is still your responsibility that your partner(s) only has access to the files relating to that assignment.

  2. Privacy and Email

    It is in your own best interest to limit the amount of access any other individual has to your account. You probably don't want other people to read your email or any other private files. Therefore, you should check to make sure that any access you grant to an individual does not allow them into any files you do not want them to see. Pay attention to what you are doing.

  3. Write Access

    It is possible to use the file server commands to allow other people to write information to your account. It is best that you limit this level of access only to those people who really need it, for a couple of reasons:

     

    • You only have a finite amount of storage space in your account. As a result, if other people write information to your account it will take up room that you could be using. It is very easy to fill up an account under normal circumstances. Also, unless you check your account all the time you may not be immediately aware that they are filling up your account, or what files they are filling it up with. This can make it difficult to untangle what was done to restore your account.

    • With the ability to write comes the ability to over-write and/or delete files. Other people who can write to your account may purposely or mistakenly alter or erase important files that you own.

     

  4. Access for Everyone

    It is possible to set up access rights to your account for groups of people, everyone that has access to the Eos/Unity system, or even anyone in the world. The only situation where you may wish to let everyone have some form of access to your account is if you set up a "public" directory for files you wish to allow anyone access to.

    It can be dangerous to set allow access to one person, but imagine the increased danger if you allow the entire student body access to your account. Be very careful.

 

The fs Command

You can change who has access to your directory using the fs command.

Syntax:

eos% fs commandname pathname loginids accesslist

 

fs fileserver command (always fs)
commandname

The file server command that you are using.

The most commonly used commands are:

sa (set access) This requires a pathname, loginid, and an accesslist.
la (list access) This can accept a pathname, or will use "." as the default.
lq (list quota) Lists information about your file quota, this is the same information as the quota command.
There are many more fs commands, but you will most likely never need to use any of them. You can find out more with:
unity% fs help

 
pathname The path to the directory that you wish to give access rights to. Many times you will be in the directory that you wish to give access rights to first, so the pathnames will be "." (current working directory).
loginids The loginid of the person you wish to give access to. This may also be a group of users. Some predefined groups are: system:anyuser (anonymous access from anyone), system:authuser (anyone on campus), and system:administrators (system administrators on campus).
accesslist

The list of access rights you wish to assign the user, being any combination or r, l, i, d, w, k, a. All or none may also be used, respectively to give all the accesses or none of them.

 

r Read access. Allows them to read, view, or copy the contents of files. They must also have look access for this to work.
l Look access. Allows them to see files in a directory. This does not allow the user to see the contents of the files, only if the files exist in a directory using the ls command. Look access in conjunction with read access allow the users to see and read files in a directory. In order to grant access to a directory, users must have look access to all directories above that directory.
i Insert access. Allows them to insert a file in a directory. This is needed to create a new file or move an existing one.
d Delete access. Allows them to delete files. If you don't give them delete access then they cannot erase a file accidentally, but they can still over-write a file if they have insert or write access.
w Write access. Allows them to write to a file. To give a user complete ability to write a file in a directory they really need to have read, lookup, insert, and write access to the directory.
k Lock access. Allows them to set an advisory lock. You will probably never use this setting.
a Administration
access.		 Allows them administrative rights to that directory, allowing them to set any and all accesses for that directory. It is not a very good idea to give other users (aside from administrators) administrative access to your account.
all All access. This gives the user all of the access, rlidwka.
none No access. This takes away any access a user may have had previously.

 

Using the fs Command

For this example, Joe Schmoe has created a web page in a www directory in his account space. He would like to give the webservers access to this directory so that they can deliver his web page. To do this, Joe knows that he needs to give look permissions to his home directory and then read and look permissions to his www directory. There is a special group, www:servers, that contains the webservers.

To begin, Joe needs to find out what the permissions are on his home directory. So he makes sure he is in his home directory, and then checks:

eos% cd
eos% fs la

and he sees this:
Access list for . is
Normal rights:
  system:administrators rlidwka
  jschmoe rlidwka

To give the webservers look, he enters:

eos% fs sa . www:servers l

And then to make sure that it has changed:

eos% fs la

and he sees this:
Access list for . is
Normal rights:
  system:administrators rlidwka
  www:servers l
  jschmoe rlidwka

 

Now Joe needs to change the access on his www directory. He either do this by changing into the directory and using "." as the path, or he can use www as the path. He decided to use www as the path.

eos% fs sa www www:servers rl
eos% fs la www
Access list for www is
Normal rights:
  system:administrators rlidwka
  www:servers rl
  jschmoe rlidwka

 

Joe then went on to work on his web page some more but ran into an error when he was trying to save his file. After making sure that he was saving it to the right place and that he hadn't taken away access to the directory he was saving it in, Joe decided to make sure he had enough quota.

eos% fs lq

(he could also have used the command quota)

eos% quota
  
Volume Name            Quota    Used    % Used   Partition
 users.jschmoe          20000   20081      101%         50%

Joe decided to finally go delete all of his old email and old files he hadn't bothered to delete in a while.

Tips On Sharing Account Space

  • Remember that you have a limited amount of storage space in your Eos/Unity account. Before you set up access permissions, or share your account, it is a good idea to houseclean a little. Go through your account and remove any unwanted or unused files. Clean up your mail folder and get rid of old messages. It is also a good idea to set up a directory structure in your account and move files into it so that your account is a more organized place.

  • Remember that with only "look" access people will only be able to see that a file exists when they use the ls command, and will not be able to read it. Use common sense when naming files, especially if other people are going to see the names. Don't do anything to embarrass yourself.

  • Communicate with other people. If you run into a problem saving files because your run out of quota, let the other person know. Also, if you are planning to take up another person's file quota, ask them before you do. Try to work together whenever possible.

  • Remember that even though it is okay to share account space to work on a project, it is NOT okay to share accounts. You are not allowed to give your password or the use of your account to anyone.
  • If you give a user or group access to a directory, then from that point on any files or directories created within that directory will inhereit those permissions. However, anything that was already there before the permissions were granted will not inherit permissions.