/etc/group problem

[wpwood3]

I spoke too soon...

For some reason the above steps did not solve my problem.
In fact, I believe it somehow led to the deletion of my entire /var/www directory when I tried later to delete mysite3 (/var/www/web3) in ISPConfig.

I think there is a bug in ISPConfig in the way it assigns group numbers.
This is the sequence of events and what happened:

1) I created Mysite1 in ISPConfig (/var/www/web1)
ISPConfig assigned web1 to GID 10001

2) I created Mysite2 in ISPConfig (/var/www/web2)
ISPConfig assigned web2 to GID 10002

3) I installed ossec (a program) and
CentOS assigned it to GID 10003

4) I created Mysite3 in ISPConfig (/var/www/web3)
ISPConfig assigned web3 to GID 10003

This won't work! web3 and ossec cannot both be 10003.

It appears that ISPConfig is not looking at the /etc/group file before it assigns group numbers. It is simply using an auto increment field in the isp_isp_web table of the IPSConfig MySQL database to generate group numbers. If that is true then it's a BIG problem!

Am I wrong?

[till]

Thats no bug in ISPConfig. The group number range that you set in ISPConfig under management > server > settings is reserved for ISPConfig. So if you create any group manually, the ID does never be in the range that you reserved for ISPConfig. Thats a prerequisite for ISPConfig.

[wpwood3]

Originally Posted by till

Thats no bug in ISPConfig. The group number range that you set in ISPConfig under management > server > settings is reserved for ISPConfig. So if you create any group manually, the ID does never be in the range that you reserved for ISPConfig. Thats a prerequisite for ISPConfig.

I am confused...

How did ossec get group 10003 if that is within the range reserved for ISPConfig?

On my test server I installed Ossec and Snort. They were assigned 10003 and 10004. Both of those groups are within the ISPConfig range.

[till]

The problem is that the rpm or apt package installer has use the next free GID and in your case, these gid's where in the reserved range of ISPConfig. which starts at GID 10000 and leaves the GID's < 10000 for other applications.

If you create a group manually, you will have to set the GID to a free ID < 10000 and make sure that thet there is no conflict with ISPConfig.

A better solution for your problem might have been to change the GID of ossec and snort right after you installed it to a GID < 10000 and change the GID of all files installed by snort and ossec to this lower GID too.

[wpwood3]

Ok, so you are saying that whenever I install any software I should inspect the GID that software was assigned in /etc/group to make sure it is not in the 10000 range?

If it is in that range then I need to edit /etc/group and change the GID for the software and also find every file installed by that software and change the ownership (chown)?

That sounds like a lot of work and potential source of errors!

Do I understand correctly?

[wpwood3]

Let me offer an alternative solution for your consideration.
I have tested this on my test server and verified that it works.

Facts as I understand them:

- With the default configuration, ISPConfig sets GID starting at 10001 and increments +1 for each new group added by using an auto increment counter in the isp_isp_web table of the ISPConfig MySQL database. ISPConfig does not verify that a GID is previously assigned before it assigns it.

- CentOS 5 (and I assume all Linux distributions) looks at /etc/group and assigns the next GID based on the highest existing GID +1.

My proposed solution:

1) Create a new dummy GID

groupadd admispconfig2

2) Edit /etc/group to change admispconfig2 GID to 20000

3) Run group check to update /etc/gshadow

grpck

4) Create a new dummy UID and add it to the admispconfig2 group

useradd -s /sbin/nologin admispconfig2 -g admispconfig2

5) Edit /etc/passwd to change UID to 20000

6) Run password check

pwck

What this does

- It forces CentOS to only create new GID's and UID's above 20000

- It allows ISPConfig to create GID's and UID's between 10001 and 19999


Comments?

[falko]

Sounds good.

[till]

Sounds like a smart solution. I added this as todo to the bugtracking system.