Many thanks to all for the wonderfully quick responses to my question.
The suggested answers included:
1) For Sun OS/Solaris:
set the password field in /etc/passwd to :x: and then set the encrypted
passwd in /etc/shadow to "NP", which locks out the account. This
appears to be a Sun OS5-specific solution. The OS4 solution is
apparently to place an asterisk in the password field of /etc/passwd.
Apparently this is the generally accepted method documented in third
party references (?) but not in the man pages (my only available
reference) - the Sun OS5 man pages indicate that there is a magic "lock"
entry that can be made, but doesn't explain what it is. Since my
/etc/shadow file had both NP and *LK* listed I didn't know how to
determine which was the correct and secure form.
It was also suggested that admin tool could be used to set the password
to "No passwd - ser[sic?]uid only" - since I don't have a video card in
my server I can't bring this up to double-check, but this sounds safer
than hacking /etc/shadow :)
2) Another person wrote: "In some WWW servers (NCSA WWW Server, for
example), you have the option for setup the daemon in mode standalone or
under the inetd; try to configure the daemon to run from inetd"
This is true, but wasn't quite the case I was describing, although that
probably wasn't clear. The process I was trying to fire off wasn't the
web server itself, but a separate application. Therefore, I can't tap
into the mechanisms that work for the server itself.
3) Another suggestion was made that perhaps the failure was due to not
having /bin/false listed in the /etc/shells file. In fact, it was
listed since my ftp user also has shell=/bin/false, leading me to
conclude that /etc/shells is not consulted in this case.
4) Finally, a recommendation was made to investigate a utility program
called OP:
"If you use OP (a program generally used to provide root access to
specific
commands), you could put in a command that starts things, but use the
USER= parameter in the op.access file. BTW, you can also use op to
provide interactive access to that user in a shell; configure a job in
op.access with USER=theuser'sID but instead of putting the command to
run, put in MAGIC_SHELL ... It will use the caller's shell for the
shell,
but set the ID to theuser'sID."
Matthew Kelly [matt@hwcn.org]
Peter Allan peter.allan@aeat.co.uk
Brion Leary <brion@dia.state.ma.us>
RAFAEL NAPOLES RODRIGUEZ [rnapoles@reduno.com.mx]
Brent Chivers bchivers@mitretek.org
>On 26 Jun 97 at 18:45, Doug Stein wrote:
>> From: Doug Stein <dstein@firstfloor.COM>
>> Reply-to: Doug Stein <dstein@firstfloor.COM>
>> To: "'Sun Managers'" <sun-managers@ra.mcs.anl.gov>
>> Subject: su <user> -c when user has no shell?
>> Date: Thu, 26 Jun 1997 18:45:35 -0700
>
>> What is the best way to handle the following situation?
>>
>> 1) My web server runs under user id httpd, which is listed in
>> /etc/passwd as having shell=/bin/false. Since no one has any business
>> using this name for an interactive login, this was meant to ensure that
>> it couldn't happen.
>>
>> 2) I have a daemon process that is supposed to run as user httpd. It
>> appears that the proper way to make this happen in my /etc/rc2.d/ start
>> script is to include a line like:
>>
>> su httpd -c "<run_this_file>"
>>
>> Unfortunately, as long as the shell is a non-login shell, this fails and
>> the daemon won't start. If I change the shell to something like /bin/sh
>> or /bin/csh, the daemon launches under user httpd and everything is
>> fine, expect that I've now opened up this potential security hole I
>> didn't want.
>>
>> Is there another mechanism that will achieve the same thing? My
>> knowledge of things like setuid scripts is limited to understanding the
>> typical warning of "Don't use setuid scripts unless you really
>> understand what is happening." I don't understand all the security
>> implications, so am not sure if this is the option I should be
>> considering.
>>
>> Any ideas much appreciated.
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:58 CDT