CDE and newgrp command conflict

[Wim Korten]

Hi,

We have set up a procedure that checks a user. Is the cluster-package active, etc, etc. If not the user gets kicked out.

Now when this is true the user is getting a newgrp to the application group and it is switching $HOME to the package location.

Now using a standard VT emulation to login, there is no problem. Ones I try this loging in in CDE (DTSOURCEPROFILE=TRUE), the user gets kicked out, right after entering it's password.

If I comment the newgrp command that is set in the .profile of the user, the user does login correct, but of course with the wrong primary group.

Does anyone know of this problem and if there is a patch or something for it?

Summary : CDE does not accept newgrp in .profile when DTSOURCEPROFILE=TRUE in the .dtprofile. Solution?


Regs David

[Sridhar Bhaskarla]

Hi David,

I would look at ~user/.dt/dt/startlog and errorlog files to more information. I am not sure if this is a problem with CDE and newgrp but you can find it out in those logs.

-Sri

[Sridhar Bhaskarla]

Hi (Again),

There is a type in my previous message. There is an extra dt in my ~user/.dt/dt/startlog. It is to be read as ~user/.dt/startlog

-Sri

[Wim Korten]

Hi Sri,

I know for sure it is. The last line says :

X connection to putd1905.intern.axa.nl:0.0 broken (explicit kill or server shutdown).

This is only when I have the newgrp command uncommented. when I comment the newgrp command I normaly log in.

Regs David

[Sridhar Bhaskarla]

Well then I would change newgrp command to something like this to capture the error retured by newgrp command.

newgrp > /tmp/cdenewgrp.err 2>&1

See if you get any pointers out of it.

-Sri

[Jeroen Peereboom]

David,

is it sufficient to have the newgrp command in .kshrc? Can you try that?

JP.

[Wim Korten]

Hi,

Sri > The error is not in newgrp, it does not even show any info when usinf the i/o redirection.

Jeroen > It does not work, how can I get a dtterm to read the .kshrc ? It does read the .profile right now (dtterm -ls).

A related question :
- I managed to find out that "who am i"does not show anything if you run the .profile during CDE login, but it does during startup of a dtterm. Using test gives me a very anoying invalid test-argument, which I did not expect in this situation :

unset who
who=`/usr/bin/who am i`

if [ -n "$who" ]
then
if [ -n "$newgrp" ]
then
newgrp $newgrp
fi
fi

The error is :
${HOME:-.}/.profile[35]: newgrp: parameter not set

This is why I had the test in, right? It's quoted, so I don't see the problem?

Regs David

[Bill Hassell]

VERY IMPORTANT: newgrp starts a new shell!!! That's why it is not desirable at all to use it in a script like .profile. Starting with 11.0, newgrp is essentially obsolete because all users inherit their primary group automatically plus any other group membership mentioned in /etc/group. For obsolete versions like 10.20, you can create this feature with this command:

ln -s /etc/group /etc/logingroup

and now, all users are automatically members of their groups...no newgrp required.

[Wim Korten]

Hi Bill,

The very important thing is that I need to change my prim-group.

whenever a user creates a file the file gets owned by it's prim-group and not by a randow other group.

Is there a different solution for this issue (maybe a new command that I can run?)

Regs David

[Jeroen Peereboom]

So newgrp must be the last command in your file ?!

JP

[Wim Korten]

nope, in that case it loops into a newgrp forever(last line in .profile, right:).

The issue is that i do not know a comand that changes your primary group in case of creating files, without the anoying habbits of newgrp that is giving you a new shell.

Regs David

[Bill Hassell]

Correct. newgrp actually execs (replaces) your current shell with a new one where the primary is as defined. NOTE: newgrp without - will not give you the same environment so your shell script should look like this:

newgrp - appgroup

As mentioned, this must be the last command in your script. The current shell and script will be replaced by the newgrp shell.

[Sridhar Bhaskarla]

Hi David,

To get around with the problem, you can check if the current session is with desktop or not using the "DT" variable. Look at .dtprofile for more information.

Also, if you have to put newgrp in your startup, then make sure you *do not* use '-' in your newgrp command. This is because the new shell will startup as if you had just logged in which means, running .profile again and again causing it to go into loop. You may be better off with a new subshell rather than this condition. It's fine if it is a standalone script though.

-Sri

[Mike Stroyan]

Apart from newgrp, changing $HOME could also lead to trouble. The default configuration uses a $HOME/.Xauthority file that holds the required authorization to use the X server. That file may be opened using $XAUTHORITY or using $HOME/.Xauthority. If neither of those lead to the right file then clients won't be able to use the X server.

[David_246]

Hi,

I found my lost password back again :)

In short we can say.
There is no alternative for changing the primary group other then newgrp, unfortunetly this command can never be executed in a .profile when using CDE and DTSOURCEPROFILE=TRUE
Unfortunetly there is a handmade script needed to adapt this. My script is as following :

# cat ~/.profile
# @(#) $Revision: 72.2 $

# User .profile file (/usr/bin/ksh initialization).

# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs

# Set up the search paths:
PATH=$PATH
export PATH
# Set the vi options
set -o vi

# Set up the shell environment:
set -u
trap "echo 'logout'" 0

# Set up the shell variables:


# Start in the new primary group, but only when a term is invoked.
unset who
who=`/usr/bin/who am i`

if [ -n "$who" ]
then
newgrp etlogrpo
fi