thread reordered for the anti top-posters... no attribution though :P
>>>> I'm getting an interesting message in Pine:
>>>>
>>>> "Folder vulnerable - Directory /var/spool/mail must have 1777
>>>> protection"
>>> Looks like a permission value to me (chmod 1777 blah), but I'm not
>>> quite sure why you'd *want* /var/spool/mail to have those
>>> permissions. Maybe it's warning you that it's world-readable?
>> The current permissions:
>> drwxrwsr-x 2 root mail 72 Feb 10 17:59 mail/
>>
>> However, '1777' is not a valid permission (they are only supposed to
>> be three digits, correct; owner, group, rest of world?), unless
>> the '1' means 'directory'.
> There are 4 digits in a file mode.
>
> The first digit is for things such as setuid, set gid, etc.
>
> The 1 in this case is often used for the "sticky bit". I'm not sure
> if Linux uses that bit the same way. I only have a Solaris system
> handy for reference.
Linux is the same way. As for the confusion of the 3 digit mode,
chmod treats those input file mode numbers kind of like a stack. chmod
7 file would give you permissions of ------rwx. 77 is ---rwxrwx. 777
is rwxrwxrwx. 7777 is rwsrwsrwt. Your /var/spool/mail mode of
rwxrwsr-x is 2775.
Unless all of your pine users are in the mail group (I hope not,
because then anyone can read/delete another's mail), or pine is sgid
mail (again, I hope not), the pine users will not be able to write to
to /var/spool/mail with your current configuration. This poses a
problem for pine, because it cannot write a lock file to that
directory, meaning that other processes may update the user's mail
file at the same time pine does, usually a recipe for corruption or
disappearing mail of some sort. Pine will run without being able to
acquire a lock on the mail spool dir, but just be aware of the
possibilities for damage.
With a chmod 1777 /var/spool/mail, pine will be able to write the
required lock file so that only one process is updating the mailbox at
a time. The 777 is so everyone can write files, but the leading 1 is
so only the owner of the file in the directory can remove the file,
even though everyone can write to the directory. 1777 is what you
want, just make sure that the user spool files within /var/spool/mail
are correctly set up with 0600 (rw-------).
chmod g+s like you have it in /var/spool/mail is meaningless for
directories. u+s (or g+s) on a binary program means the program can
run with the effective uid (or effective gid) of the owner of the
program. It is required in many circumstances (like /usr/bin/passwd,
since it must read and update /etc/shadow), but good practice is to
code your programs to avoid the requirement if possible. o+t is
sticky bit for a directory, already addressed above, meaningless for
programs, but comes in very handy for publicly writable directories.
~ Daniel
________________________________________________________________
The best thing to hit the Internet in years - Juno SpeedBand!
Surf the Web up to FIVE TIMES FASTER!
Only $14.95/ month - visit www.juno.com to sign up today!
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:38:33 EDT