[development] using UID 1 (was Re: Overriding node_db_rewrite_sql())
agentrickard at gmail.com
Thu Jul 26 22:35:01 UTC 2007
Greg, I don't have edit permissions, so here are some thoughts.
In this particular case, the argument is:
User 1 does not behave like other users, so testing module functionality as
user 1 is generally a bad idea, since you won't get to see the actual
role-restricted behavior of your module. This is especially true of node
In general, two additional points:
* In our uses, we always have multiple administrators. So we treat user 1
like Unix root or sudo. Not everyone should act under sudo at all times,
and we never login as 'root'. You need to be able to trace who did what.
(However, that said, user 1 does leave a record, so perhaps the analogy
doesn't quite hold up.)
* Our corporate security policy is violated by user 1 because user 1
violates the rule of least privilege. Moreover, since we have multiple
sysadmins who install Drupal sites, our user 1 tends to be a role account,
which is a violation of our security policy (one person to an account).
Now this second point isn't relevant to the entire Drupal community,
obviously, but it also makes a case for replacing the special user 1
entirely with a default 'administrative user' role that is assigned to user
1 and can then be assigned to other users.
So, in practice, we always create the site. Create a new 'administrator'
role. Give that role all privileges. Create a new user as an
administrator. Then logout as user 1 and never use that account again. To
run update.php, we just set the access check to FALSE.
It may also be that our security policies are bad, but that's beyond my
- Ken Rickard
On 7/26/07, Steven Jones <darthsteven at gmail.com> wrote:
> Two Administrators
> On 26/07/07, Cog Rusty <cog.rusty at gmail.com> wrote:
> > On 7/26/07, Greg Knaddison - GVS <Greg at growingventuresolutions.com>
> > > On 7/26/07, Ken Rickard <agentrickard at gmail.com> wrote:
> > > > Development testing should never be done as user #1 unless testing
> > > > installation or update routines. In fact, nothing but install and
> > > > should be done as user #1.
> > > >
> > > > See http://drupal.org/node/22284
> > >
> > > I see your point here about how it has been confusing to Ron that uid1
> > > could see everything, but I'm not sure I follow the rest of the logic.
> > > To me, I don't see a problem with using uid1. I know lots of folks
> > > feel strongly about this, but there's also a prominent case or
> > > two of smart people doing otherwise. There is even the whole
> > > masquerade code in the devel module which makes it easy to switch
> > > between uid1 and a normal user during development to facilitate Ron's
> > > exact situation.
> > >
> > > Just yesterday I edited bullet item 1 on 22284 to include all of the
> > > arguments on this issue that I was able to glean from the folks that
> > > were in IRC when I was digging into the issue. Given that
> > > investigation and rewrite, I don't understand the strength of the
> > > "don't use uid 1" argument.
> > >
> > > So, if folks feel strongly one way or another could they please edit
> > > that page (or respond here) with some of the reasons why you should
> > > "never use user #1".
> > Ok, I added a 4th reason:
> > "On a community site, if the top administrator is using account #1 for
> > all things, including personal content in blogs, forums, etc, and
> > later administration passes to someone else, the previous
> > administrator's content will be in account #1 and will have to be
> > moved, which is not a very trivial task."
> > > If you're going to say "for the same reasons as you never use root on
> > > unix" then please take the time to enumerate those reasons - I'm not
> > > sure I believe that comparison so having the list of reasons would
> > > help the discussion.
> > >
> > > Regards,
> > > Greg
> > >
> > >  http://drupal.org/user/1
> > >  http://groups.drupal.org/user/1
> > >
> > > --
> > > Greg Knaddison
> > > Denver, CO | http://knaddison.com
> > > World Spanish Tour | http://wanderlusting.org/user/greg
> > >
> Steven Jones
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development