Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2004
    Location
    florida
    Posts
    12

    Unanswered: processadmin role

    I'm trying to allow my developers the ability to modify/execute their jobs and dts packages in production....without giving away the security farm so to speak.

    Is the processadmin role a possibility?

    BOL and the net only seems to say this role allows user to "manage process"...duh.

    Your thoughts and advice would be great appreciated.

  2. #2
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    The processadmin server role conveys the ability to kill a process (SPID) in SQL Server. Can't say as I would be comfy with a lot of people with that ability, myself.

    In order to create/delete jobs, they will need access to the msdb database (by default all users do), and permissions on the following stored procedures, which also default to public:

    sp_add_job
    sp_add_jobschedule
    sp_add_jobserver
    sp_add_jobstep
    sp_delete_job
    sp_delete_jobschedule
    sp_delete_jobserver
    sp_delete_jobstep
    sp_start_job
    sp_stop_job
    sp_update_job
    sp_update_jobschedule
    sp_update_jobstep

  3. #3
    Join Date
    Mar 2004
    Location
    florida
    Posts
    12

    Thank...

    If I give them this kind of access in msdb, won't it give them job and dts access to all databases?

  4. #4
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Jobs and DTS packages are stored only in the msdb database, so yes. That's just the way the system is set up. If their user ids can access all databases, you would have had that, anyway. I am not sure if a user can try to specify a different user to run a job.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •