samba-2.0.5-pre1 - PLEASE TEST

[Cole, Timothy D.]

> -----Original Message-----
> From:	Andrew Tridgell [SMTP:tridge at samba.org]
> Sent:	Thursday, July 15, 1999 9:03
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	samba-2.0.5-pre1 - PLEASE TEST
> 
> Report problems to this list as soon as possible.
> 
	Okay, in smbd/nttrans.c, call_nt_transact_set_security_desc():

	    /*
	     * Check to see if we need to change anything.
	     * Enforce limits on modified bits.
	     */

	    if(fsp->is_directory) {

	      perms &= lp_dir_security_mask(SNUM(conn));
	      perms |= lp_force_dir_security_mode(SNUM(conn));

	    } else {

	      perms &= lp_security_mask(SNUM(conn)); 
	      perms |= lp_force_security_mode(SNUM(conn));

	    }

	This should instead be:

	    /*
	     * Check to see if we need to change anything.
	     * Enforce limits on modified bits.
	     */

	    if(fsp->is_directory) {

	      perms &= lp_dir_security_mask(SNUM(conn)) | sbuf.st_mode;
	      perms |= lp_force_dir_security_mode(SNUM(conn)) & ( perms ^
sbuf.st_mode );

	    } else {

	      perms &= lp_security_mask(SNUM(conn)) | sbuf.st_mode;
	      perms |= lp_force_security_mode(SNUM(conn)) & ( perms ^
sbuf.st_mode );

	    }

	details:

	Notice that the comment (which is from my original patch) indicates
that the limits should be enforced on _modified_ bits.  The existing code in
2.0.5-pre1 will enforce the limits on all bits, whether or not they have
been modified relative to the existing permissions.  I do not think the
latter behavior is desirable.

	I'm sorry to keep harping on this one issue, but I feel that it's
pretty important.

	rationale:

	The existing behavior (munging all permissions, changed or not) is
dangerous, as it happens invisibly to the user, and without apparent user
intervention:  all the user has to do is _look_ at the permissions and press
'OK', and they will be (silently) changed, even though he is not aware he
has changed anything.  Even if he does change something, other bits that he
did not change may be changed anyway, granting more or allowing less access
than the user had intended.

	As long as the sysadmin explicitly sets the security mask/force wide
open, that's not likely to be very much of a problem, but for anyone else,
especially for someone upgrading an older configuration, it's a hidden and
very subtle trap.

	supporting scenarios:

	Let us transport ourselves to the near future...

	scenario #1:

		Joe Sysadmin had deployed Samba on one of the machines in
his NIS, and more recently upgraded to 2.0.5 from 2.0.3.  He had set the
create mask to 0750 previously, but forgets to add a security mask = 0777 to
smb.conf (as he would presumably be instructed by documentation).  He
discovers his mistake a couple days later, and goes back and fixes it ... no
harm done, right?

		That Saturday, he's at dinner with his wife on the other
side of the city when his pager goes off.  It's a certain user who is in
charge of a particular mission-critical process that was supposed to run
Friday night, but has started mysteriously failing.

		After a few hours of poring through logs and arguing with
the user about the meaning of "nothing changed", he discovers that a
particular file that ought to be 660 is now 640.  Odd.  He chmods it back to
660 and things start working again -- the particular group needed to have
write access to the file.  Of course, by then it's 1:00am on Sunday.

		It turns out that the user in question had discovered and
been playing with his new ability to look at and manipulate the permissions
of his Unix files from his NT PC.  He'd played a little with a couple files
in his home directory, but wanted to see a file with some different
permissions.  So, he picked that particular file to look at, since he knew
about it and owned it and it had different permissions.  He didn't change
anything, but he had pressed 'OK' to close the dialog.

	(This was before Joe had fixed the security mask)

	scenario #2:

		Elsewhere, a SAMBA (2.0.5) share has been set up on a Unix
box so various folks in a project can share some files, although the
aforementioned Unix box is also used for other things.  Force group and
force mode (0660) have been set on the share to make sure that everyone in
the project has read/write access to the files in the directory.

		Late one Friday night, a certain employee on the project
discovers that he's nearly out of disk space on his PC.  He deletes a few
things that he knows he doesn't need anymore, but that doesn't help very
much.  So he can keep working, he gathers a bunch of his less-used files
together and sticks them on the aforementioned share.

		Some of these are not things that he wants his fellow
employees reading, including a particularly biting invective about his boss
and his behaviors with certain farmyard animals.  He didn't entirely mean
it, mind you, or intend to publish it in any fashion; it's just one of those
things that people are wont to write for the sake of working out their
frustrations out on paper and eventually intend to destroy.  (I would
question the wisdom of writing such things, especially electronically, but
still, people write them)

		Knowing a little about how the permissions are set up, he
knows that the files are going to be readable by everyone in the project
unless he changes them, so he opens up the permissions dialog and removes
read and write permission for the group.  He presses 'OK'. Feeling paranoid,
he opens the dialog again.  Good thing, too -- the permissions don't appear
to have changed.  He concludes that setting permissions via SAMBA is broken.


		Fortunately, he has a normal account on the Unix box, and
Knows Just Enough Unix To Hang Himself(tm), so he logs in and chmods the
files to 600.  Then he looks at the permissions from the permissions dialog
again.  Just to be sure.  Much to his relief, he sees is now the only user
with read (or write) access to them.

		He presses 'OK'.

		The next Monday, he returns from lunch to find a message
from his boss on his voicemail...

	---

	... any similarity to events or persons living or dead is purely
concidental, and I hope it stays that way. :)