<[EMAIL PROTECTED]> wrote: >> > The reason why smbpasswd with -j and -r option does not work is probably > because it's executed from a user which is not considered as "root" by > Samba/VMS. > > Presently, the user is considered as "root" only if his UIC is either [1,4] > or [1,1]. I kept this feature from an older Samba/VMS port. However, I don't > like it too much.
In SAMBA 2.0.6 for OpenVMS, the requirement that SMBPASSWD be run from the SYSTEM UIC is a bug. SMBPASSWD needs to be specially coded to for OpenVMS so it can be installed with GRPPRV so that users can change their own SMB passwords. GRPPRV is needed to access the UAF file to verify that the user exists. It will also allow users to be able to change both their VMS passwords and LANMAN passwords at the same time. On the UNIX version, the SMBPASSWD is SETUID to root. This is equivalent to it being installed as a shared image with privileges under OpenVMS. The internal tests in SMBPASSWD are meant for that if it is really runing as root, instead of a non-privileged user, it provides additional functionality. > Here is a couple of propositions about that. Could you tell me which one > looks good for you (you can make other ones, too...) ? > > 1. the user is root if his UIC group is within the SYSGEN parameter > MAXSYSGROUP > 2. if it has some identifier (like SAMBA_ROOT) > 3. If his USERNAME is SYSTEM My plans for a future FRONTPORT shared image is similar to that if the current real USER account has SYSPRV, that it would pass the SAMBA root tests. Currently FRONTPORT allows the program to designate what account is "root", or 0,0. The default is SYSTEM. There is no real reason for the SMBD to run with all the privileges of the SYSTEM account. This change to FRONTPORT would make UNIX programs that test for "root" to behave more like OpenVMS users expect. Have you reviewed the FRONTPORT documentation from the SAMBA 2.0.6 port? -John [EMAIL PROTECTED] Personal Opinion Only
