[ale] Multiuser and Email (Long)

[Mike Kachline]

-----BEGIN PGP SIGNED MESSAGE-----


	Michael,

	Hopefully the following will help you out.

>1. I have decided to learn some more of the multiuser aspects of Linux.
>What I want to know, is how do I make directories and files invisible to
>a user, but not to others? 
<snip>
	The easiest way that I can think of off the top of my head would be to
create groups for your users. More on the technicalities of this later though
(It seems as if you already suspected this). Before reading on, read through the
man pages for "chmod(1)", "group(5)" and "chgrp(1)".





<snip>
> Also, can I make certain programs available to
>certain users and not to others?
<snip>
	In a nutshell, create a group for your "special" users, chgrp your
executables to this new group, then chmod the files g+x o-x.




> I don't quite understand the concept of
>groups either. Does the group permissions override individual? For
>example, if a file is invisible to a certain user, but not to the group
>he belongs in, which takes precedence?
<snip>
	The basic idea is that for any file or directory (which are pretty much
the same thing from Linux's standpoint), you can set the file/directory's
owner's, group's or "others" permissions. Changing the permissions for the
owner of the file (which can only be done by the owner of the file or root)
changes what one specific person (ie, the owner) of that file/directory can do
to the file. Why is this handy? Well, in case you want to set one of your data
files as being "read only", then the implicit here is that you are setting the
file to be "read only by yourself, the owner". Note that, as long as you are
the owner of the file/directory, you can't permanently "lock yourself out" of
one of your own files. For instance, if you chmod'ed a file to be read-only
with something like "chmod u-w foo.txt", then you could always just "chmod u+w
foo.txt" to get your permissions back.

 	Setting the "group" permissions of a file/directory allows all other
users who are members of the same "group" as the group which is associated with
the file to do whatever you specified (ie, read, write, or execute). Whereas
setting "owner" permissions only affects one person, the owner of a file;
setting "group" permissions allows a slightly higher subset of folks (ie a
group of users) to have the same permissions to a file. Note that only a file's
owner (or root, of course) can chmod a file. Thus, if you make a file
executable by it's group but not "others", folks within the file's "group"
can't go in and chmod the file to also be executable by "others".

	Finally, setting the "others" permissions of a file/directory specifies
what your "general user" can do to the file. Of course "general user" in this
sense meaning users who are not the owner or not in the same group which is
associated with that file.


	Ok, so your next logical question here would be "how do I create groups
of users?". This is pretty easy to do. You should have a file called
/etc/group. This file is consisted of lines conforming to the pattern of:

 group_name:passwd:GID:user_list

	...where "group_name" is the name of the group, "passwd" will have to
be explained by someone else on the list (I haven't used this feature enough to
confidently describe it's usage), GID is an integer value uniquely representing
the group, and "user_list" is a comma separated list of users who belong to the
group. 	Thus, if you wanted to add "jim" "bob" and "mary" to the "folks" group,
you would have an entry in your /etc/group line which looked something like:

folks::1001:jim,bob,mary.

	Now that your group is created, say that you wanted to make the 
"/usr/local/bin/folks_program"  program executable only by jim,  bob and mary.
To do this, you would simply:

#chgrp folks /usr/local/bin/folks_program 
#chmod g+x /usr/local/bin/folks_program 
#chmod o-x /usr/local/bin/folks_program

	The first line associates the "folks_program" with the "folks" group.
Doing an "ls -la /usr/local/bin/folks_program" should show this.
	The next line sets permissions on the program to be executable by the
group which is associated with the program. Finally, the last line ensures that
the "folks_program" is *not* executable by users who are not within the folks
group, or the file's owner.



>
>2. Can I use the email accounts created in linux for each account without
>having a full time web server? (I wish I could have one, but money
>prohibits. :(  )
<snip>
	You'll have to re-ask this question. I can't understand what exactly
you are asking about here.



<snip>
>3. Also, I have seen reference in the HOWTOs to files and directories
>that begin with a period, and don't show up in ls, but when I edit the
>directory (which I discovered by accident) in emacs, it shows the
>existence. Is there a way to show these in ls? Why are they invisible?
<snip>
	"ls -la" usually will do it. "find -print" can also give you a
recursive walkthrough of your directory structure.
	As far as answering as to "why are these directories/files invisible"?
It is done mainly as a conviniece to both programmers and to users. Many times,
programs will store their configuration files in your home directory under a
".somethingoranother" name. This is done from the programmer's standpoint
because it is easier to find the path of your home directory, and it is almost
assured that you will be able to create / write to files in your own home
directory. From the user's standpoint, it is an "out of site, out of mind" kind
of thing. If all of my configure files were visible, I would probably have the
habit of deleting some of them, just to save myself the sanity of having to
sort through dozens of them every time I ask for an "ls".



							Hope this helps,
									- Mike
============================================================================
Michael Kachline CS, Georgia Institute of Technlology
kachline at cc.gatech.edu
http://brightstar.gt.ed.net/kachline
============================================================================

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNo32Lrp4G55ObFUlAQElSQP+LIBECmkhYESYsdlkOKjY6QHu2u7DL186
yph6thp/e92CCAe8+eGIVjJCP8ZOy3GjkwNmvcZHpChLOU8eYMcc/ETtqWLMtdo6
wLfDuk16eFobXZcJjY/MxFOi1UwvYwr/+V1zJ1NWW624qgKEHOGQPOLc1p1Zf6Fp
+TAT98ixVbw=
=JIU1
-----END PGP SIGNATURE-----