joined accounts

[warmongr]

I want to create seperate log ins for about 15 users, however I want their initial home directory to be the same. I am have a few problems with this.<br>
<br>
1. I create the accounts as follows:<br>
useradd -c "Joe Blow" -g groupnamehere -d /home/userhome accountname<br>
where groupnamehere is the name of somegroup and userhome ...<br>
2. I've created the directory in /home/userhome and set the perms:<br>
chmod 775 userhome<br>
chown :groupnamehere userhome<br>
3. I've set the perms on all files in the userhome directory to match the directory (Does that make sense? 775)<br>
<br>
Problem:<br>
<br>
- Only the original owner of the directory can login successfully the first time.<br>
- When I try and log in via one of the other accounts X seems to reset itself and comes back to the log-on screen.<br>
- When I view the files in /home/userhome, the owner of the files is set to the account that last attempted the log-on and the group remains set to groupnamehere<br>
- When I try and log on via the original owner it begins doing the same; restarting X<br>
- I can su successfully without a problem as in:<br>
<br>
su accountname<br>
<br>
Any ideas? is there an X configuration or kde configuration file that is having issues here?<br>
<br>
War...

 

[warmongr]

amplifying info:<br>
<br>
Renaming the .xsession file in the default directory allows all users to share directories. The problem from here is that there are applications that are being launched out of the .xsession file that are needed by the users. Any ideas for fixes or work arounds. Any ideas at all. I'd even be happy to hear your idea on bologna sandwiches at this point.<br>
<br>
war...

 

[mckarl]

bologna?? that like bolognaise?? sounds pretty italian to me... <br>
<br>
Think i may have has some of that stuff on holiday in greece, not over here in the UK though. <br>
<br>
Well, maybe in some italian restuarants... or something, why someone would put bolognaise on a butty i dont know, but they are italian after all, diffrent traditions and all that. i mean who'd ever think of mad cow desease anywhere but in the UK?? <br>
<br>
My point exactly...<br>
<br>
Karl

 

[AndyBo]

This sounds like a security problem related to file ownerships etc. and X. I'm not near my Linux box at the mo, so I can't check this.<br>
<br>
You've not explained why you need to have a shared home directory for the users. If they need their own .xsession files, wouldn't it be easier to give each user their own home directory?<br>
<br>
If the user's need to share, for eg, a .profile, save the standard .profile somewhere accessable by everyone and make the only entry in the user's .profile <br>
<br>
. /my/standard/profile<br>
<br>
This will source and execute the shared profile.<br>
<br>
HTH.

 

[warmongr]

Thanks for the response AndyBo,<br>
<br>
The reason that we need shared directory is because we are a software development company. The machines that we use are used for one purpose only: to test and run the software. We initially had a group log-on that they all used to run exercises, however because of extenuating circumstances. (gov't security req's for C2). In either case, individual accounts are required. What I need to know is why X will not allow them to share the directory when the perms on the directory are all 775 recursively and all belong to the same group. Each user is created in the following way: <br>
<br>
useradd -d /home/joint_dir_ame -g primary_group username<br>
<br>
a umask of 002 is added to the .cshrc file <br>
<br>
We are using AfterStep and have a custom .steprc file (which is at the root of all the problems.)<br>
<br>
These machines are constantly being torn down, reconfigured and rebuilt again so a overcomplicated program like NIS+ is not an option.<br>
<br>
any ideas at this point. Anything would help.<br>
<br>
war...

 

[AndyBo]

Thanks for the extra info. I understand the problem a little better now. I worked for a development company for five years, and we needed similar setups. Fortunately, we never had to conquer X <br>
<br>
From the little I know on the subject, I suspect it's X that's causing your problems. X needs root access to do certain things (like accessing some hardware directly, I think), and it's gained a reputation as something of a security hole. Even though visible permissions would seem to be OK, I suspect something in X is saying "Hang on, this user doesn't own this home directory. Time to bail out..."<br>
<br>
Can you set things up so that the users can login from a character based session? (telnet, perhaps.) I suspect they'll be allowed to log in OK, and have normal shell access.<br>
<br>
I'm not sure how you could move on from there. It might be worth digesting man pages on xauth and xhosts. They might show a way around the X problem.<br>
<br>
Sorry I can't be more help