Securing important files (was-REDHAT 6.1 blah, blah...)
landrew at pnl.gov
Tue Dec 21 19:33:07 GMT 1999
On Wed, 22 Dec 1999, Luke Kenneth Casson Leighton wrote:
Subject_Was: Re: URGENT: REDHAT 6.1 STORES SAMBA PRIVATE FILES IN /etc
} > > i know what damage can be done with those .mac files. you can anonymously
} > > use them to obtain remote SAM databases.
} > > it scares me that people might not realise this, and think it's ok to
} > > change the permissions on them, or edit them.
Just wondering why smbd (and testparm) doesn't test that the permissions
are correct on these important files before using them. If we know that
these files shouldn't be set wide-open, then the daemon should complain
and/or refuse to function if they are set incorrectly.
If there is a legitimate reason to open the permissions up, then an
override via a command line switch (so it can't just become part of some
standard configuration file or Makefile/build) could be used. If the
server *knows* something is supposed to be secure and it's not, it
shouldn't run (and it should spit out an error in the logs.)
} root manually editing the smbpasswd file, a umask that allows a saved file
} to have read permissions set to more than owner, file is being saved
} temporarily as smbpasswd.new, then copied to smbpasswd after backing up
} the old one.
Checking permissions and not starting the daemon under unsafe conditions
will solve these problems by making it clear something is wrong up front
(assuming the Sys Admin that just made the change doesn't want her
customers complaining and has checked that there are no feet in the way of
More information about the samba-technical