[Info-vax] SAMBA and Ransomeware

John E. Malmberg wb8tyw at qsl.net_work
Fri Jul 28 19:24:18 EDT 2017


On 7/28/2017 5:17 PM, Stephen Hoffman wrote:
> On 2017-07-28 20:08:16 +0000, Arne Vajhj said:
> 
>> What does VMS Samba actually require?
> 
> More than TMPMBX and NETMBX, depending on the component.    The Samba 
> testparm tool tips over with a stackdump if you don't have SYSLCK 
> enabled for instance, and that requirement was undocumented on the 
> versions I was working with.

The SYSLCK is needed probably for simulating byte range locking and 
implementing op-locks.

It also needs a privilege for listening on a privilege port.

Samba needs "CMKRNL,SYSPRV" privileges because it needs to accept a 
connection and after authenticating the user, has to access the file as 
the user.

Samba V3 does this by starting as a privileged user and then when the 
authentication process is done, it does a change user to that user and 
drops any privileges that user does not have.  Not sure if it retains 
any privileges the user has that are not needed for Samba, as I have not 
looked at the HP VMS port source.

The Samba V3 model is based on the premise that once the connection is 
authenticated, all transfers on that connection will be for the same user.

That turned out to be only mostly true, and Samba put in a hack to deal 
with it.  On the ports previous to the HP VMS port, that hack did not 
get implemented, but no-one ever reported a problem to the samba-vms 
mailing list about it.

I do not know if the HP VMS port implemented the hack or not.

The Samba V4 threaded model eliminates the hack, but then requires Samba 
to run at elevated privileges since all thread must be the same user. 
There were alleged to be performance and scaling improvements for using 
the threaded model.  Unfortunately I while I got most of Samba V4 
building on VMS, I never got enough built to properly test it.

Full building of Samba V4 required a newer Kerberos and OpenLDAP client 
than VMS had at the time.  And while the then current OpenLDAP client 
mostly built on VMS, it needed access to a non-public OpenSSL routine, 
so it could not be built on VMS with the then existing OpenSSL packages.

A fully functional Samba V3 port also needs those things.

One of the more interesting things I had in the Samba V4 port is mapping
named pipes to SYS$ICC services, so had I completed the port, it may 
have been able have only one windbindd process needed for a cluster.

Regards,
-John
wb8tyw at qsl.net_work



More information about the Info-vax mailing list