NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Anne,
Some post-mortem info.
Adminstrative ports will not usually open at the socket layer
without administrative privlege. Since the port mapper service already
runs at root privaledge, you don't need it a second time. But, it is
needed somewhere along the line to open 388, as you say. Typically, the
rpc.ldm is owned by root & it is setuid root ("stickey bits") as mentioned.
This causes it to execute as root, regardless of the ownership of the user
process invoking it, hence opening a socket on 388 is allowed. The user
process needs permission to run this the same as any other executable file,
too.
In todays security conscious world, I expect that this problem
will resurface as administrators tighten security holes. Setuid programs
are often a security hole.
jdm
At 11:01 AM 1/18/2001 -0700, you wrote:
>Brad Teale wrote:
>>
>> I was wondering why the specifications for the ldm say to chown rpc.ldmd to
>> root. If the ldm is registered with the portmaper (/etc/rpc), then the
>> portmaper specifies which port ldm will be using. Also, if ldm uses rpc,
>> why are we specifying the 388 port in the /etc/services file?
>>
>> I am asking because, when I run rpc.ldmd as the ldm user, my pqact and
>> pqbinstats programs start-up and run great. Where as, if rpc.ldmd is
>> chowned to root, they never start and no errors are produced.
>>
>> Thanks,
>> Brad Teale
>> Universal Weather & Aviation, Inc.
>> <mailto:bteale@xxxxxxxxxxxx>
>> 713-944-1440 ext. 3623
>
>Brad,
>
>For some historical reason, it was decided that the ldm would use one of
>the hard-wired, system service ports (ports less than 1024) rather than
>relying on the portmapper. I believe the ldm will run using the
>portmapper service if it doesn't have access to port 388.
>
>Simply listing the ldm in /etc/services and ldmd in /etc/rpc doesn't by
>itself allow the ldm to get to the port. My understanding is that those
>files serve mostly to map from numbers to strings for informational
>purposes. The ldm still needs root priveleges to get port 388.
>
>Our standard installation has rpc.ldmd owned by root and setuid root,
>and expects the ldm to be started via user ldm. The idea is that the
>ldm has root priveleges temporarily, just long enough to get port 388,
>then it reverts back to ldm level priveleges because it was invoked by
>user ldm. This is what the permissions should look like on rpc.ldmd:
>
>-rwsr-xr-x 1 root ustaff 441385 Sep 8 10:54 rpc.ldmd*
>
>This has worked for us on many sparc workstations.
>
>Were you originally invoking the ldm as root? If you were, it possible
>that root will not exec programs that it suspects are unsafe. Were
>there any messages in the system log?
>
>Also, it is better to send questions of this nature to
>support@xxxxxxxxxxxxxxxx, rather than to this list. Please respond to
>me directly.
>
>Thanks!
>
>Anne
>--
>***************************************************
>Anne Wilson UCAR Unidata Program
>anne@xxxxxxxxxxxxxxxx P.O. Box 3000
> Boulder, CO 80307
>----------------------------------------------------
>Unidata WWW server http://www.unidata.ucar.edu/
>****************************************************
>
James D. Marco, jdm27@xxxxxxxxxxx, jmarco1@xxxxxxxxxxxx
Programmer/Analyst, System/Network Administration,
Computer Support, Et Al.
Office: 1020 Bradfield Hall, Cornell University
Home: 302 Mary Lane, Varna (607)273-9132
Computer Lab: 1125 Bradfield (607)255-5589
ldm-users archives: