Date: Wed, 10 Jul 1996 16:23:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrm@MARMOT.Mole.ORG (M.R.Murphy) Cc: terry@lambert.org, igor@cs.ibank.ru, jim@starshine.org, questions@freebsd.org Subject: Re: Samba FS planned to implement? Message-ID: <199607102323.QAA27662@phaeton.artisoft.com> In-Reply-To: <199607102236.PAA02228@meerkat.mole.org> from "M.R.Murphy" at Jul 10, 96 03:36:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Suppose that one were to look at this in a slightly twisted manner. > Suppose that the SMB FS client is a FreeBSD box, and that the > SMB (Samba) server is also a FreeBSD box. One could set up the > server so that the client (and _all_ of its users, therefore) > was suitably restricted. Samba's pretty good at that. That NT or Win* > might not be quite as good still does not keep the facility from > being useful. If usefulness outweighs security concerns, why not > have the facility? If it doesn't, then don't allow the sharing. > This is a policy matter. This is the "common share" model. The only answer I have for this is "by default, the choice to allow security compromises should be explicit rather than implicit". I've said, several times before, "feel free to implement code, which I will subsequently refer to as 'broken', but don't expect me to do it". > If the administrator of the SMB server wants to grant access to > some set of users on a FreeBSD box and is willing to act in > concert with the administrator of the FreeBSD box, especially > since the administrators might be one in the same person, why > should that not be an available security mode? I'd give you examples > with group permissions and such on the mount directory, but you'd > give better examples than I would. > > I draw your attention once again to the quote in my signature :-) > > Regards, > Mike > -- > Mike Murphy mrm@Mole.ORG +1 619 598 5874 > Better is the enemy of Good The status quo is the enemy of progress. Once implemented incorrectly, you remove the majority of the incentive to implement it correctly at a later time... examples: msdosfs, PnP, FS stacking, the ft driver, the kernel timer changes necessary for timer outcall and/or oneshots in drivers, the use of the "cookie" paradigm to solve the stat buffer translation issues for the NFS server code, the use of the slice code to put off the need to integrate devfs, etc., etc.. Better is the enemy of good because good so often wins that better has gotten a bit pissed about the whole situation. The maxim "anything which works is better than anything that doesn't" is *much* stronger than the maxim "better is the enemy of good". 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607102323.QAA27662>