homedir permission

[Crystal_1]

Hi,

I set up umask as 027 within the /etc/profile. But why when I create a new user, its home directory permission is 755?

But any directories I created under this homedir, the permission is the same as what I think, 750...

Crystal

[Pete Randall]

Crystal,

How are you creating the user?
The creation process is setting permissions on the home directory without regard to your umask.

Pete

[Helen French]

Just tried the same thing in my test system and it worked fine for me ! It created the $HOME directory with permission 750. I 've created the user with SAM and before that changed my umask to 027.

Before adding the users, check the umask with:

# umask

[Crystal_1]

Hi,

I put the umask in /etc/profile as 027 and logged out and logged on...

Then ran the command "useradd -m test", and check the permission of /home/test, it is
drwxr-xr-x.

I tried several systems and they gave me the same result...

Crystal

[Crystal_1]

Hi,

I did another test:

1.Change the umask from 027 to 022 in /etc/profile, log out and log on.

2. useradd -m testnew
3. the new homedir is the same 755

If it is true that no matter what the umask is, it won't change the home directory's permission.

Now my question is :

Can I change this defaul setting to make the new created homedir 750?

Tx, Crystal

[Helen French]

what is the output of 'umask' ?

Did you try creating with sam ? are you getting the same result there ?

[S.K. Chan]

Nothing wrong with your umask setting. I'm not sure but I think the "useradd" command has it's umask hardcoded as 755, that's why no matter what umask you set, it'll not work at the home dir level. Either you don;t use "useradd" or manually change the home dir permission afterwards.

[Helen French]

Again, I suspect you have another umask set in the local profile ($HOME/.profile). This will overwrite the /etc/profile 'umask' value. Confirm this with command:

# umask ( display current umask)

During my test, the HOME directory was created depend on the umask. So I believe the same.

Setting permission to $HOME directories is up on your wish. But if you share the same HOME directory with another user/group, then set the permission accordingly. To change permission:

# chmod
# chown

[Martin Johnson]

I think useradd has a hardcoded 755.

You have to be careful using useradd because it also does a "chown -R" to change the ownership of the files in the home directory.

I had an SA who set up a pseudo root account with / as his home directory. All the files on the system were subsequently owned by him. This was a pop3 mail server. Mail delivery was broken until I restored the files to their proper owners.

Marty

P.S. The SA now has a nickname of "chown boy".
:-)

[Helen French]

Again, tested the same with 'useradd' command and found the HOME directory permission is 755, even if the umask is set to 027. So I think 'useradd' keeps the permission always as 755, but SAM takes input from 'umask' value.

[Martin Johnson]

Have you viewed the SAM log to see what qualifiers it is using to add a user?


Marty

[Helen French]

Martin:

I think the last question was for me. Yes, I checked it during that time and found SAM uses this command/script for adding user, create home directory, copy files from /etc/skel etc:

/usr/sam/lbin/upusrfiles

[Martin Johnson]

yes Shiju, the question was directed at you. I was just wondering if you could find out how SAM uses the umask values.


After the "chown boy" incident, we have frowned upon using useradd and use SAM to create new users. The only problem we have with SAM is creating accounts with duplicate UIDs.

We use duplicate UIDs (including the use of UID 0 - pseudo root) for auditing purposes. It is not recommended by HP, but auditing wants accountability. What auditing wants, auditing gets.

Marty

[Crystal_1]

Guys,

This is really intresting.

Martin: I had same problem with you.

Why I raised the issue here is because I used the SAM to create a new id which is exactly the same as another account "ftp". After I created the account, I got a problem. The new account took over the "ftp" account, which means "ftp" was replaced by the new account name. This was not what I expected. Others cannot use "ftp" login name at that moment....

I did some investigation and found that if I ran the command useradd with the option -o, I could get the problem fixed. Tow duplicate accounts can exist on the system. So,I ran it. Unfortunately, I got a new problem, because the ftp account is required to have 555 permission for its home directory. When I checked the permission of ftp homedir, it was changed to 755. "ftp" couldn't be used again.

Guess what? The problem mentioned above happened on a trusted machine. When I tested it on an untrusted machine, the ftp home directory permission wasn't changed and the ftp account could be used.

I was thinking that was because of umask setting. Actually, it is not related...

It really made me confused...

[Rory R Hammond]

The solution is to customize sam's add user routines.

"man sam" should tell you how.

I can't remember the exact procedures. I set it up years ago.

Generally. I have a file called /etc/sam/custom.tasks

It has one line:
UG_ADD_USER POST /etc/sam/doprofile


/etc/sam/doprofile is my profile customization script.
If you need more help email me and I will give you samples and procedures.

Rory

[Martin Johnson]

When using duplicate UIDs, I use SAM to set up the account with a unique UID, then I edit /etc/passwd to change the UID to the duplicate, followed by using chown to change the ownership of the newly created home directory.

Marty

[Jack Werner]

Just FYI,
In our shop we recognized that using NFS to cross-mount filesystems would raise huge issues if we didn't enforce uniqueue UID NOs.
I built a script that nightly gathers every NIS server's /etc/passwd file and those of a few critical servers that don't use NIS. The script massages the aggregate password files and produces a UID.REGISTER file. Errors are emailed to the root recipients of each platform that identify UID collisions and handle(ie loginname) collisions.
We add users to each platform manually by assigning the next UID available by vi'g the UID.REGISTER file and entering the placeholder which "reserves" the new UID. Then we simply create the user's /etc/passwd entry, add the user to any groups (except their default group), make their IAP(home account), setting the permissions and ownerships and finally set the user's initial password.
We have a similar need to control our GIDs but this is an issue we haven't tackled yet

[Martin Johnson]

Crystal,

How about a little encouragement? Assign some points!

:-)
Marty