This is slightly off-topic from the original post so I'm changing the subject.
On Dec 9, 2007 6:30 PM, Shai Gluskin shai@content2zero.com wrote:
Here is the handbook page that describes why not using user/1 for day-to-day is a best practice:
I don't think the conclusion you've drawn is really reflected in the meat of the page. That's especially true if you use an account that is granted a role that has all permissions on a site - that account is just as vulnerable to most of the security problems listed on that page.
The only thing that the "user 2 with all privileges" setup gets you is a small amount of protection on security holes/actions in the update.php file. But if you have a "user 2 with all privileges" then that person probably has access to php input format and can do a lot of damage to your site (which is worth a reminder: if you don't need it then disable the php input format).
Regards, Greg
Greg and all,
Thanks for changing the topic.
My main reason was touched on briefly in the handbook node. But I'll elaborate.
Users are people. Users can then get assigned to none, one or more roles. But what is weird/unique to user/1 is that it is essentially a role, not a person. It's a role with unique properties which no other user can be assigned. So what do you do when you want to rotate or share the privileges/responsibilites that user/1 posesses. Typically person->user is a one-one relationship. (more precisely it's e-mail -> user).
It's better for no person to be user/1 but rather that the privileges/log-in info should be available to the person or persons at any given time who need to have superadmin access (e.g. the person or persons in charge of software updates).
Normally there isn't a use case for a user changing user ids; there is a use case for people migrating in/out of having access to superadmin privileges.
To concretize it, here is a simple example. A guy starts a business, in his spare time; he's the only employee. He figures out Drupal and launches his site as user/1. The site turns out to be very successful and grows the business. The founder has created a large volume of content for the site as user/1. But now the guy has employees. His site has also grown in complexity and someone else is administering it. He's in the awkward situation of having to give his employee who administers the site access to his user account in order for the employee to administer the site. And it's not a trivial matter to migrate all his content to another user.
Shai
On 12/9/07, Greg Knaddison greg@pingvox.com wrote:
This is slightly off-topic from the original post so I'm changing the subject.
On Dec 9, 2007 6:30 PM, Shai Gluskin shai@content2zero.com wrote:
Here is the handbook page that describes why not using user/1 for
day-to-day
is a best practice:
I don't think the conclusion you've drawn is really reflected in the meat of the page. That's especially true if you use an account that is granted a role that has all permissions on a site - that account is just as vulnerable to most of the security problems listed on that page.
The only thing that the "user 2 with all privileges" setup gets you is a small amount of protection on security holes/actions in the update.php file. But if you have a "user 2 with all privileges" then that person probably has access to php input format and can do a lot of damage to your site (which is worth a reminder: if you don't need it then disable the php input format).
Regards, Greg
-- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg -- [ Drupal support list | http://lists.drupal.org/ ]
Shai Gluskin wrote:
He's in the awkward situation of having to give his employee who administers the site access to his user account in order for the employee to administer the site. And it's not a trivial matter to migrate all his content to another user.
see http://drupal.org/project/adminrole
Neil
On Dec 10, 2007 12:36 AM, Neil Adair neila@magma.ca wrote:
Shai Gluskin wrote:
He's in the awkward situation of having to give his employee who administers the site access to his user account in order for the employee to administer the site. And it's not a trivial matter to migrate all his content to another user.
Neil - the discussion so far is about whether or not something like adminrole is a good idea. My contention is that if you believe that using UID1 is bad then using adminrole is nearly as unsafe.
If you use adminrole but also remove many of the privileges then it becomes more safe. However, most paranoid people feel that it's better to consciously enable permissions than have that happen automatically.
Regards, Greg
To me it seems that user/1 doesn't really fit the Drupal data model. You have the instance of an object which is too different from all the other instances of the object. User/1 is one obstacle that slows down Drupal from becoming object-oriented.
One workaround of the current design would be to grant user/1 all permissions except... node/add and comment/reply. This would, at least, put a thick wall between super administrator and content creator functionalities.
Shai content2zero http://content2zero.com
On 12/9/07, Greg Knaddison greg@pingvox.com wrote:
On Dec 10, 2007 12:36 AM, Neil Adair neila@magma.ca wrote:
Shai Gluskin wrote:
He's in the awkward situation of having to give his employee who administers the site access to his user account in order for the employee to administer the site. And it's not a trivial matter to migrate all his content to another user.
Neil - the discussion so far is about whether or not something like adminrole is a good idea. My contention is that if you believe that using UID1 is bad then using adminrole is nearly as unsafe.
If you use adminrole but also remove many of the privileges then it becomes more safe. However, most paranoid people feel that it's better to consciously enable permissions than have that happen automatically.
Regards, Greg
-- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg -- [ Drupal support list | http://lists.drupal.org/ ]
On Sunday 09 December 2007, Shai Gluskin wrote:
To me it seems that user/1 doesn't really fit the Drupal data model. You have the instance of an object which is too different from all the other instances of the object. User/1 is one obstacle that slows down Drupal from becoming object-oriented.
I do not comprehend how having a "root" user account has anything to do with object-orientation whatsoever.
The only thing "magic" about uid 1 is that the user_access() function always returns true for uid 1, and the update.php script (normally) only runs for uid 1. There's nothing else special about it, and certainly nothing that involves objects.
On Dec 10, 2007 6:34 AM, Larry Garfield larry@garfieldtech.com wrote:
I do not comprehend how having a "root" user account has anything to do with object-orientation whatsoever.
The only thing "magic" about uid 1 is that the user_access() function always returns true for uid 1, and the update.php script (normally) only runs for uid 1. There's nothing else special about it, and certainly nothing that involves objects.
This is being discussed here : http://drupal.org/node/196296
Philippe
Greg Knaddison wrote:
Neil - the discussion so far is about whether or not something like adminrole is a good idea. My contention is that if you believe that using UID1 is bad then using adminrole is nearly as unsafe.
I agree, but it seemed to be what he wanted. I just create a webadmin role, admin is rarely required on a production site.
Neil
Quoting Greg Knaddison greg@pingvox.com:
This is slightly off-topic from the original post so I'm changing the subject.
On Dec 9, 2007 6:30 PM, Shai Gluskin shai@content2zero.com wrote:
Here is the handbook page that describes why not using user/1 for day-to-day is a best practice:
I don't think the conclusion you've drawn is really reflected in the meat of the page. That's especially true if you use an account that is granted a role that has all permissions on a site - that account is just as vulnerable to most of the security problems listed on that page.
Yes, which is why I asked the question, how is it different? The answer is of course that it isn't. And worse if you have a DBA that also has an account the DBA could easily change his role status.
The only thing that the "user 2 with all privileges" setup gets you is a small amount of protection on security holes/actions in the update.php file. But if you have a "user 2 with all privileges" then that person probably has access to php input format and can do a lot of damage to your site (which is worth a reminder: if you don't need it then disable the php input format).
So my suggestion is to use user/1 for administration and use some other user for creating content. If you want to give privileges to another user, pick and choose what you want the user to do in the new role, don't just blindly give them full privileges.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/