It is currently Tue, 07 Dec 2021 02:23:51 GMT



 
Author Message
 NFS, mail and file permissions, wierd problem...
Mojn!

I have the following problem: A number of Linux workstations (Slackware 2.3.0)
have /var/spool/mail NFS mounted on a SGI running IRIX 4.0.5h (I know, it's
not very clever but better than noting...:) This enables the person(s) working
on the Linux machines (witch masquerades as our mail server) to read and send
mail from their local machines. The problem is that whenever elm (runnig SGID
mail) writes to the mailbox, the file permissions change to 600 instead of 660
for the mail file (chown user.mail). When running elm with /var/spool/mail on
the local machine it does not change the permissions.
When the permissions change, sendmail cannot write to the mail file and all
new mail goes into the great bit bucket :( What is wierder still is that local
mail gets delivered properly (even if it was sent from one of the masquerading
machines) but remote mail fails. sendmail on the server is running SUID root
and SGID mail... Does anyone have a clue?

thanx, jonas
--
        " Why does a bundle of stable compounds such as carbon,
          hydrogen, oxygen and nitrogen struggle for millions
          of years to organize themselves into a professor
          of chemistry? What is the motive? "



 Fri, 10 Apr 1998 03:00:00 GMT   
 NFS, mail and file permissions, wierd problem...
I've encountered similar problems with Linux NFS (2.1) in a heterogeneous
environment. If I've read your message properly, the Linux box is
exporting /var/spool/mail to IRIX, and updating a spool file (from IRIX)
which lives on this filesystem changes the permissions of the file. If
this assumption isn't correct, read no further. :)

I suspect the file is inheriting the umask of the process updating it.
There's a bug in nfsd which causes an inappopriate resetting of the
attributes of an existing file, at least between SunOS and Linux. I
wouldn't be surprised if it affected nfs interoperability between IRIX and
Linux, as well.

I've a patched nfsd which solves this, and a few other problems
(specifically, a mismatch between systems -- IRIX, SunOS, and ULTRIX --
which provide attributes.mode as an unsigned short rather than the
unsigned int that Linux expects, causing Linux nfsd to believe that the
file attributes need to be updated unnecessarily, and preventing remote
users from updating files to which they have group, but not owner, access.
This happens because the user-mode nfsd tries to chmod a file it doesn't
currently own).

Write me if you'd like the code, and i'll put it up on an ftp site.

Regards,
-c
c...@cs.washington.edu



 Thu, 23 Apr 1998 03:00:00 GMT   
 
   [ 2 post ] 

Similar Threads

1. mail problem: file permissions for lock file

2. Wierd AIX/NFS client, Sun/NFS server problem

3. wierd file permissions

4. NFS file permission problem.

5. NFS : problems with file permissions

6. mail file permissions in /var/mail

7. NFS: file permissions denied problem

8. wierd nfs file

9. wierd permissions problem running pppd


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software