[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #HVX-774667]: "execv( /home/mcidas/bin/mcservsh ) failed: Permission denied" on 64-bit redhat 5.0 enterprise
- To: venus@xxxxxx
- Subject: [McIDAS #HVX-774667]: "execv( /home/mcidas/bin/mcservsh ) failed: Permission denied" on 64-bit redhat 5.0 enterprise
- From: "Unidata McIDAS Support" <support-mcidas@xxxxxxxxxxxxxxxx>
- Date: Fri, 11 Apr 2008 12:07:13 -0600
- Delivered-to: support-mcidas@unidata.ucar.edu by laraine.unidata.ucar.edu (Postfix) with ESMTP id F07EFCB18C; Fri, 11 Apr 2008 12:07:13 -0600 (MDT) id D48BED4FBA; Fri, 11 Apr 2008 12:07:13 -0600 (MDT)
Hi Tyn,
re:
> further to your suggestions i verified that:
> The 'mcadde' account is sharing the 'mcidas' HOME directory.
Excellent.
> However, to get to this stage i had to use the following command on the terminal:
>
> /usr/sbin/usermod -d /home/mcidas mcadde
>
> -d, --home HOME_DIR new home directory for the user account
>
> To get this right as the gui version "Users and groups" would mess up the rights for "mcidas"
> (and couldn't login afterwards with all kind of permission denied issues on
> .bash_profile, .gnome and a-like).
I would have used 'vipw' run as root. This allows you to edit the /etc/passwd entries (and
the shadow file) directly/easily.
> Also, in RHEL 5.0 there is no "/bin/false" option by default,
> but i hacked the /etc/shells and include an item for this and verified /bin/false actually existed.
There might be a /sbin/nologin equivalent to /bin/false. If there is, I would recommend
using it.
> Are there any security things i could check here, both users "mcidas" and "mcadde"
> are part of the same group "mcidas"?
As long as the umask in the 'mcidas' account is set to '002' before the distribution
was unpacked and the executables built, etc., 'mcadde' should be able to share the
data without problems.
re: compression used
> This is as you say: MCCOMPRESS=GZIP
> I did install compress and decompress btw.
OK. This should be a non-issue as long as the installation directory
is included in the PATH that is in scope for ADDE server invocations
that are run to fulfill client requests. For the remote server, this
might mean that PATH has to be adjusted in ~mcidas/.mcenv.
I have the feeling that there is something simple/small that is missing
or a bit incorrect. I can typically find little problems easily if
I have a login as 'mcidas', so I am still interested in getting SSH
access to the machine.
Cheers,
Tom
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
support@xxxxxxxxxxxxxxxx Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: HVX-774667
Department: Support McIDAS
Priority: Normal
Status: Closed