2.2.8 source save set protections

[John E. Malmberg]

In article <CF0913E9C3D53D4E94DE47FDE25C633D048FD450 at hermes.cofiroute.com>,
COLLOT Jean-Yves <jean-yves.collot at cofiroute.fr> writes:
> >
> - by adding the /INTERCHANGE switch in my BACKUPs commands. In fact, I
> sincerely though that there was no site-dependent ACLs in the kit, but
> I was wrong. Shame on me.

I have no idea if there were site-dependent ACLs, I just mentioned them as
a possibilty.

> - All files will be owned by SYSTEM ([1,4]) and  correctly protected
> (S:RWED,O:RWED,G:RE,W)

With the /INTERCHANGE, the ownership on the files does not matter.

I have determined that one of the biggest mistakes that I did on the SAMBA
2.0.6 port was building and testing it under the SYSTEM account.

That was responsible for my missing some very elementary problems with that
port.

In my current build environment for all home projects, I have the distribution
source protected from write access from the build account, and I do the build
from an account with only netmbx and tmpmbx.

Any automated privileged testing is done from a dedicated account and
controlled through DECNET proxy access.

Manual testing is also done from a dedicated account with limited privileges.


To be consistent with the OpenVMS security model, SMBD, NMBD, and SWAT should
each get dedicated accounts with only the privileges that SAMBA needs.

This should not take too much work, and if I actually find some time to do some
coding to a future SAMBA release, that is the way I would implement it.  It is
mainly an issue of what account is aliased to the UNIX root account.

> - I'll find some way to give a specific name to upcoming versions. What =
> do
> you think of adding the release date (such as =
> samba-2_2_8-09-AUG-2004.zip) ?

A date is nice, but as history has shown, sometimes more than one release
is made per day.  That is why a build number may be better.

-John
wb8tyw at qsl.net
Personal Opinion Only