The way DA handles users and groups

California

Verified User
Joined
Aug 19, 2004
Messages
48
Hi!

Just a newbie question: Does DA track all permissions itself? When I look in my /etc/group file just about every group has no users assigned.

For example, when I create a user in DA called xyzuser, a group called xyzuser gets created as well, but the user "xyzuser" does not show up in the group "xyzuser" in /etc/group. Is this normal?

I would think that a group named for a DA user would at least have that user in the group. Just wondering...

FreeBSD 4.9
 
The operating system takes care of the user and groups.

I believe it is normal. In my groups file it only has the username and number. Groups are the same as the username unless specifically modified through your OS.
 
Hi Hi!

I have another question pertaining to the way DA handles users:
When I add a new user under a reseller group and assign to it a domain, there does not seem to be any way to modify that admin username.

Am I going to be forced to create an entirely different user account and transfer configurations across everytime a customer wants to change his administrator username?
 
At this time yes, you will have to create a new account transfer the files and delete the old one. This was the same for domain name changes which was a recent feature addition.

Possibly a feature request? mmmm, its a borderline feature in my opinion. But if it were to be implemented maybe something like the Admin user can change anyone's username and resellers can only change usernames under them.
Personally I wouldn't want this option to be available for everyone to change their own usernames whenever they felt like it.

The most likely thing to happen will probably be a 3rd party script or plugin do everything manually. Anyone have some spare time? :p
 
Last edited:
jmstacey said:
The most likely thing to happen will probably be a 3rd party script or plugin do everything manually. Anyone have some spare time? :p
It's not as easy as you think, since usernames are in file paths as well as in the contents of many files, all of which would have to be changed.

And kind of robust solution would also have to look the passwd, group, and shadow files while the change was taking place, to make sure no two people could overwrite each other with changes to the same username.

And since root can write to any file, even if it's marked read-only, the only way to do that would be to rename the files.

And that would disallow server logins during the lock period, as well as impacting lots of services that require starting as root and then changing to another user.

It's not a job to take on lightly. And probably not something I'd ever implement on my own server; what if the server crashed while those files were in a locked (renamed) state. You couldn't log in to your server again until you fixed them in single-user mode (which must be done at the data center, using a keyboard and monitor).

Jeff
 
Back
Top