Michael seemed to admit...
>It's my fault the account doesn't have PM/SM on it when you install it; when
>we originally packaged the FREEWARE tape, we tried to not add PM/SM accounts
>to the system.  Since the smbd and nmbd programs need PM, we put them in a
>group named SAMBA.SYS.  We later realized that the jobs running the daemons
>need to be logged on with SM, and that they must be logged into the SAMBA
>account.  For the next release, I hope HP will everything from SAMBA.SYS back
>to PUB.SAMBA, and give the account PM/SM.

No SM for MGR.SAMBA, please. It only needs to get PM, if you want to
"allow" it password validation and setuid() user switching. It does not
even need it for technical reasons, as the SMBD program has PM and thus
resides in SAMBA.SYS with PM. I just thought, it might be a good idea
to protect the "innocent" (eg those who did not read the PM related note
in the ReadMe file, which happens to be samba7c.htm or .txt on 6.0) to
not make them open their system "unexpectedly". If someone wants more
than guest shares (accessed as MGR.SAMBA), they need to grant PM to the
server job user explicitly. I do not consider SM for MGR.SAMBA a good
idea (for obvious reasons).

Looking back, I would probably have done better by introducing users
like SERVER.SAMBA and GUEST.SAMBA instead of doing all with MGR.SAMBA
(which tends to be confusing). Well, nowadays, I would probably also
get rid of the SAMBA account completely and put all the stuff under
/SYS/SAMBA/... to keep it in one place, maybe using a SAMBA.SYS user
for the server job.

I'm using an IX account for all my porting since quite some time now,
with each project having a dedicated group (and user) instead of a
whole account (with only a PUB group in most cases). So this would be
like @.SAMBA.IX, @.JSERV.IX, @.INFOZIP.IX, @.ENHYDRA.IX, @.WGET.IX,
etc. For ports that are supported by HP, the SYS account would be more
appropriate, of course ;-) but that's an easy modification ;-)

Lars (not speaking for @grc.hp.com here)