Search Results

Search found 158 results on 7 pages for 'sudoers'.

Page 1/7 | 1 2 3 4 5 6 7  | Next Page >

  • Installing ZFS changed my sudoers file

    - by MaxMackie
    Following the wiki's advice, I installed ubuntu-zfs. However, once everything installed correctly, and I tried installing another application via apt-get, I get a weird issue with my sudoers file: max@host:~$ sudo apt-get install deluge deluge-web sudo: /etc/sudoers.d/zfs is mode 0644, should be 0440 >>> /etc/sudoers.d/README: /etc/sudoers.d/zfs near line 18 <<< sudo: parse error in /etc/sudoers.d/README near line 18 sudo: no valid sudoers sources found, quitting *** glibc detected *** sudo: double free or corruption (!prev): 0x08909d08 *** ======= Backtrace: ========= .... Why has zfs messed with the sudoers file? I can post the backtrace if needed.

    Read the article

  • Add AD Domain user to sudoers from the command line

    - by Wyatt Barnett
    I'm setting up an Ubuntu 11.04 server VM for use as a database server. It would make everyone's lives easier if we could have folks login using windows credentials and perhaps even make the machine work with the current AD-driven security we've got elsewhere. The first leg of this was really easy to accomplish -- apt-get install likewise-open and I was pretty much in business. The problem I'm having is getting our admins into the sudoers groups -- I can't seem to get anything to take. I've tried: a) usermod -aG sudoers [username] b) adding the user names in several formats (DOMAIN\user, user@domain) to the sudoers file. None of which seemed to take, I still get told "DOMAIN\user is not in the sudoers file. This incident will be reported." So, how do I add non-local users to the sudoers?

    Read the article

  • How to generate customized sudoers files in puppet depending on the environment they're deployed to?

    - by gozu
    the sysadmins are present in the sudoers files of all environments, but other sudoers are not. Different environments all have slightly different sudoers. Most of the time, 90% of users are the same, and 10% vary so we cannot have only one sudoers file for everything. Right now, we are using puppet with 10 different files with names like sudoers.production1, sudoers.production2, sudoers.production3, sudoers.testing1, sudoers.staging1 and so forth. Puppet then picks the file to deploy based on the server's $domain (ex: dbserver.staging1.acme.com) or $hardwaremodel. It works fine but it's a nightmare to maintain so many files. I'd like to autogenerate sudoers files based on the server's domain and have only one big file with all the sudoers permissions for all users and all environments. Something that looks like: User_Alias ADMINS = abe, bob, carol, dave case $domain { "staging1.acme.com" { #add dev1,dev2,tester1,tester2 to sudoers file } "testing2.acme.com" { #add tester1, tester3, tester4 to sudoers file } What's the best way to go about this? Suggestions for alternatives are welcome. I'd appreciate any tips. Update 1: For security reasons, we'd rather not concatenate a bunch of files from a folder located on a puppet client in case someone puts a file in there (maliciously or not) and either breaks the combined file or inserts something in it. Most importantly, for usability, we'd like to keep the number of sudoers related files (fragment or complete) on puppet server to either 3 (prod/stage/test) or preferably 1 file. this file would (somehow) generate sudoers files on the puppet server and send one customized file to each puppet client. The purpose of this would be only searching for a username in a single file and removing it quicker than doing it on 11 files. When adding a user to a bunch of environments, it won't be as quick, but only one file would need to be opened and looked at, greatly reducing the chances of an omission. our Sudo version is 1.6.9p8 so we can't use /sudoers.d folder, only a sudoers file.

    Read the article

  • sudoers - simple explanation requested

    - by Redsandro
    Everytime I want to be able to run something that requires me to be a sudoer too many times, I need to google for the formatting of /etc/sudoers to remind me again what exactly is the proper way to write it. Now I see different writing styles in my sudoers file, which is the consequence of different google results over the months. I've also noticed that the second example (below) seems to work in XFCE, but not in Cinnamon (Gnome 3). This could be totally unrelated, but nontheless I'd like to know once and for all, what is the correct grammar of the sudoer line, and what is the difference between the given examples? redsandro ALL=NOPASSWD:/path/to/command redsandro ALL=(ALL) NOPASSWD:/path/to/command redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command Also, what are all the ALL's for? One user, one command, yet I need to use the ALL keyword up to three times? Am I doing this wrong? Of course, omitting NOPASSWD: makes you enter your password before you are permitted to run the command, but one point of confusion is the usage of = and :, for the final command that is the subject of the line can be prepended by either =, :, , or ), confusing grammar for similar semantics.

    Read the article

  • Centralized sudo sudoers file?

    - by Stefan Thyberg
    I am the admin of several different servers and currently there is a different sudoers file on each one. This is getting slightly out of hand as quite often I need to give someone permissions to do something with sudo but it only gets done on one server. Is there an easy way of editing the sudoers file just on my central server and then distributing it by SFTP or something like that to the other servers in an easy way? Mostly wondering how other sysadmins solve this problem, since the sudoers file doesn't seem to be remotely accessible with NIS, for example. Operating system is SUSE Linux Enterprise Server 11 64-bit, but it shouldn't matter. EDIT: Every machine will, for now, have the same sudoers file. EDIT2: The accepted answer's comment was the closest to what I actually went ahead and did. I am right now using an SVN-supported puppet-installation and after a few headaches, it's working very well.

    Read the article

  • sudoers file cleanup and consolidation tool/script

    - by Prashanth Sundaram
    Hello All, I am curious to know what other folks out there might be using to keep the sudoers file in a sane manner. I am looking for a tool, that removes redundant entries, overlapping permissions and/or present sudoers file in a organized way(like sorting by permissions/users/Aliases) User_Alias RT1123 jappleseed, sjobs Host_Alias HOST_RT1123 wdc101.domain.com, wdc104.domain.com Cmnd_Alias ..... Our sudoers file is simple but a lot of entries and it needs to be cleaned up. Does anyone know/have a tool/script to fix/present it ? Thanks!

    Read the article

  • sudoers entries

    - by Pochi
    Is there a way to have a sudoers entry that allows executing of only a particular command, without any extra arguments? I can't seem to find a resource that describes how command matching works with sudoers. Say I want to grant sudo for /path/to/executable arg. Does an entry like the following: user ALL=(ALL) /path/to/executable arg strictly allow sudo access to a command exactly matching that? That is, it doesn't grant user sudo privileges for /path/to/executable arg arg2?

    Read the article

  • Get sudoers information for all users on a server

    - by Jon Kruger
    I want to collect information on what sudoers actions a user can perform on a server. From what I've read, you can do this with the command sudo -l -U username. However, one server that I have has a slightly older version of sudo (1.6.7p5) and the -U option doesn't seem to exist (I don't own the server so I can't just upgrade to a newer version of sudo). Has anyone ever had to collect sudoers information for all users on a server? How would you recommend doing it?

    Read the article

  • Using NOPASSWD for specific commands in sudoers file, PASSWD for all others

    - by jberryman
    I would like to configure sudo such that users can run some specific commands without entering a password (for convenience) and can run all other commands by entering a password. This is what I have, but this does not work; a password is always required: Defaults env_reset Defaults timestamp_timeout = 1 root ALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) NOPASSWD: /usr/sbin/pm-suspend, /usr/bin/apt-get, PASSWD: ALL #includedir /etc/sudoers.d Note that this is a debian system which uses this adding users to the "sudo" group method. Thanks.

    Read the article

  • sudoers security

    - by jetboy
    I've setup a script to do Subversion updates across two servers - the localhost and a remote server - called by a post-commit hook run by the www-data user. /srv/svn/mysite/hooks/post-commit contains: sudo -u cli /usr/local/bin/svn_deploy /usr/local/bin/svn_deploy is owned by the cli user, and contains: #!/bin/sh svn update /srv/www/mysite ssh cli@remotehost 'svn update /srv/www/mysite' To get this to work I've had to add the following to the sudoers file: www-data ALL = (cli) NOPASSWD: /usr/local/bin/svn_deploy cli ALL = NOEXEC:NOPASSWD: /usr/local/bin/svn_deploy Entries for both www-data and cli were necessary to avoid the error: post commit hook failed: no tty present and no askpass program specified I'm wary of giving any kind of elevated rights to www-data. Is there anything else I should be doing to reduce or eliminate any security risk?

    Read the article

  • Sudoers file allow sudo on specific file for active directory group

    - by tubaguy50035
    I have active directory sign in working on an Ubuntu 12.04 box. When the user signs in, I have a script that runs that needs sudo permission (since it modifies the samba config file). How would I specify this in my sudoer's file? I've tried: %DOMAIN\\AD+Programmers ALL=NOPASSWD: /usr/local/bin/createSambaShare.php I've found various resources on the internet stating that this is how it would be done, but I'm not sure that I have the first part right. What are they using as the DOMAIN? The workgroup or the realm? I use Samba + winbind for active directory integration. Here's my smb.conf: [global] security = ads netbios name = hostname realm = COMPANYNAME.COM password server = passwordserver workgroup = COMPANYNAME idmap uid = 1000-10000 idmap gid = 1000-10000 winbind separator = + winbind enum users = no winbind enum groups = no winbind use default domain = yes template homedir = /home/%D/%U template shell = /bin/bash client use spnego = yes domain master = no EDIT: The users that should have access to run that script are all part of the Programmers group which has an Active Directory Domain Services Folder of Company.com/Staff/Security Groups (not sure if that matters or not).

    Read the article

  • How do I use saz-sudo puppet module to deploy my own sudoers file with hiera?

    - by mr.zog
    I have saz-sudo installed and have created a site_sudo module based (I hope) on it. Here's what I have in my site_sudo/manifest/init.pp file: class { 'site_sudo': } sudo::conf { 'web': source => 'puppet:///files/etc/sudoers', } sudo::conf { 'syseng': priority => 10, content => "%sysadm ALL=(ALL) NOPASSWD: ALL", } include sudo No matter what I do, the sudoers file on the target is always overwritten with the sudoers.rhel6 file from saz-sudo module. I'm using common.yaml too: classes: - site_sudo

    Read the article

  • Cannot do sudo: "/etc/sudoers is mode 0740, should be 0440"

    - by dehmann
    I have a problem: I don't have a root password on my mac. I just have an Admin account, which can do stuff using sudo. Now, I wanted to add my normal user to the /etc/sudoers file as well. Since it did not let me write to that file (even writing using sudo), I did this: sudo chmod u+w /etc/sudoers That worked. But since then I can't do any sudo command anymore on my system. It complains that /etc/sudoers has the wrong mode: $ sudo touch /etc/sudoers sudo: /etc/sudoers is mode 0740, should be 0440 Segmentation fault It sounds like a bad joke, because now I can't even change the mode back to 0440: $ sudo chmod 0440 /etc/sudoers sudo: /etc/sudoers is mode 0740, should be 0440 Segmentation fault Is there any way to fix this situation? I need to get my sudo abilities back.

    Read the article

  • What do the "ALL"s in the line " %admin ALL=(ALL) ALL " in Ubuntu's /etc/sudoers file stand for?

    - by sri
    What does each ALL mean? I understand that the whole line indicates that the admin group members get admininstartive privileges, but would like to know more info about the position of the ALLS and if they each refer to a different set of permissions or something like that? $sudo cat /etc/sudoers ... # User privilege Information root ALL=(ALL) ALL #... %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d #Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # If it matters: OS: Ubuntu : 10.4

    Read the article

  • Broken Sudo - sudo: parse error in /etc/sudoers near line 23

    - by Robert Fáber
    I am getting this error: sudo: parse error in /etc/sudoers near line 23 sudo: no valid sudoers sources found, quitting sudo: unable to initialize policy plugin I was trying to disable password authentication so I don't have to type password every time I want to install something, but I probably changed it in a not very good way. I am a newbie to Ubuntu, I got sick of Windows :) So far I've found some people suggesting booting in single user mode, but I'm afraid of messing things up more.

    Read the article

  • sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0

    - by 7UR7L3
    Whenever I try to do anything at all that requires my password it returns this: u7ur7l3@ubuntu:~$ sudo sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0 sudo: fatal error, unable to load plugins u7ur7l3@ubuntu:~$ So I can't install anything from the Software Center / package manager or run any commands in terminal that require my password. I can log in, but that's pretty much it. I accidentally changed the permissions of some files, then changed some more trying to fix it :/. Now I'm completely lost as to what to do. This is what happened when I tried to get sudo working again using pkexec: u7ur7l3@ubuntu:~$ pkexec chown root /usr/lib/sudo/sudoers.so Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success u7ur7l3@ubuntu:~$ sudo ls sudo: /usr/lib/sudo/sudoers.so must be owned by uid 0 sudo: fatal error, unable to load plugins And to change permissions I was using Root Actions as a dolphin service/ plugin thing, so history doesn't show me the permission changes. I just realized that sounds don't work at all anymore. When I go into Phonon my default settings and playback devices aren't even there. Also I don't have the option to shutdown, I can only log out or leave.

    Read the article

  • Troubleshooting sudoers via ldap

    - by dafydd
    The good news is that I got sudoers via ldap working on Red Hat Directory Server. The package is sudo-1.7.2p1. I have some LDAP/Kerberos users in an LDAP group called wheel, and I have this entry in LDAP: # %wheel, SUDOers, example.com dn: cn=%wheel,ou=SUDOers,dc=example,dc=com cn: %wheel description: Members of group wheel have access to all privileges. objectClass: sudoRole objectClass: top sudoCommand: ALL sudoHost: ALL sudoUser: %wheel So, members of group wheel have administrative privileges via sudo. This has been tested and works fine. Now, I have this other sudo privilege set up to allow members of a group called Administrators to perform two commands as the non-root owner of those commands. # %Administrators, SUDOers, example.com dn: cn=%Administrators,ou=SUDOers,dc=example,dc=com sudoRunAsGroup: appGroup sudoRunAsUser: appOwner cn: %Administrators description: Allow members of the group Administrators to run various commands . objectClass: sudoRole objectClass: top sudoCommand: appStop sudoCommand: appStart sudoCommand: /path/to/appStop sudoCommand: /path/to/appStart sudoUser: %Administrators Unfortunately, members of Administrators are still refused permission to run appStart or appStop: -bash-3.2$ sudo /path/to/appStop [sudo] password for Aaron: Sorry, user Aaron is not allowed to execute '/path/to/appStop' as root on host.example.com. -bash-3.2$ sudo -u appOwner /path/to/appStop [sudo] password for Aaron: Sorry, user Aaron is not allowed to execute '/path/to/appStop' as appOwner on host.example.com. /var/log/secure shows me these two sets of messages for the two attempts: Oct 31 15:02:36 host sudo: pam_unix(sudo:auth): authentication failure; logname=Aaron uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=Aaron Oct 31 15:02:37 host sudo: pam_krb5[1508]: TGT verified using key for 'host/[email protected]' Oct 31 15:02:37 host sudo: pam_krb5[1508]: authentication succeeds for 'Aaron' ([email protected]) Oct 31 15:02:37 host sudo: Aaron : command not allowed ; TTY=pts/3 ; PWD=/auto/home/Aaron ; USER=root ; COMMAND=/path/to/appStop Oct 31 15:02:52 host sudo: pam_unix(sudo:auth): authentication failure; logname=Aaron uid=0 euid=0 tty=/dev/pts/3 ruser= rhost= user=Aaron Oct 31 15:02:52 host sudo: pam_krb5[1547]: TGT verified using key for 'host/[email protected]' Oct 31 15:02:52 host sudo: pam_krb5[1547]: authentication succeeds for 'Aaron' ([email protected]) Oct 31 15:02:52 host sudo: Aaron : command not allowed ; TTY=pts/3 ; PWD=/auto/home/Aaron ; USER=appOwner; COMMAND=/path/to/appStop The questions: Does sudo have some sort of verbose or debug mode where I can actually watch it capture the sudoers privilege list and determine whether or not Aaron should have the privilege to run this command? (This question is probably independent of where the sudoers database is kept.) Does sudo work with some background mechanism that might have a log level I could turn up? Right now, I can't fix a problem I can't identify. Is this an LDAP search failure? Is this a group member matching failure? Identifying why the command fails will help me identify the fix... Next step: Recreate the privilege in /etc/sudoers, and see if it works locally... Cheers!

    Read the article

  • How to configure sudoers to always keep LD_LIBRARY_PATH envrionment variable?

    - by Yanick Girouard
    No matter what I try, it seems that the LD_LIBRARY_PATH environment variable is not kept after I run a command with sudo. The only way I managed to have it stick, is to prefix my sudo command with LD_LIBRARY_PATH=/the/path whenever I call it from the command-line, but I would like to not have to do this every time. It seems the env_keep option ignores this variable, and so does the exempt_group option. My %group currently has ALL=(ALL) NOPASSWD:ALL as its access in sudoers. I would like this specific environment variable to be kept for any command I run. How can I do this? My server is running Red Hat Enterprise Linux 5.7.

    Read the article

  • How to avoid specifying full path in sudoers file?

    - by s g
    I am trying to add a NOPASSWD entry for sudotest.sh (or any script/binary that requires sudo) in my /etc/sudoers file (on Ubuntu 12.04 LTS server), but in order to make it work, I must specify the full path. The following entry works just fine: %jenkins ALL=(ALL)NOPASSWD:/home/vts_share/test/sudotest.sh The problem is that the script might move to a different directory. This seems like a great chance to use the * wildcard in the path (i.e. /*/sudotest.sh) so that my script could be in any directory but the manual states that wildcards will not match the / character when used in a path. I've confirmed that it doesn't work. I know that I can use the word ALL in place of my script, but this means there is no password prompt for any commands which seems unsafe. How do I solve this?

    Read the article

  • Security implications of adding www-data to /etc/sudoers to run php-cgi as a different user

    - by BMiner
    What I really want to do is allow the 'www-data' user to have the ability to launch php-cgi as another user. I just want to make sure that I fully understand the security implications. The server should support a shared hosting environment where various (possibly untrusted) users have chroot'ed FTP access to the server to store their HTML and PHP files. Then, since PHP scripts can be malicious and read/write others' files, I'd like to ensure that each users' PHP scripts run with the same user permissions for that user (instead of running as www-data). Long story short, I have added the following line to my /etc/sudoers file, and I wanted to run it past the community as a sanity check: www-data ALL = (%www-data) NOPASSWD: /usr/bin/php-cgi This line should only allow www-data to run a command like this (without a password prompt): sudo -u some_user /usr/bin/php-cgi ...where some_user is a user in the group www-data. What are the security implications of this? This should then allow me to modify my Lighttpd configuration like this: fastcgi.server += ( ".php" => (( "bin-path" => "sudo -u some_user /usr/bin/php-cgi", "socket" => "/tmp/php.socket", "max-procs" => 1, "bin-environment" => ( "PHP_FCGI_CHILDREN" => "4", "PHP_FCGI_MAX_REQUESTS" => "10000" ), "bin-copy-environment" => ( "PATH", "SHELL", "USER" ), "broken-scriptfilename" => "enable" )) ) ...allowing me to spawn new FastCGI server instances for each user.

    Read the article

  • How to configure sudoers with path wildcards?

    - by C. Lee
    I need sudo for a command for any path under a particular area. Example: sudo mycommand /opt/apps/myapp/... What is the sudoers syntax to allow this command to run in any path that falls under /opt/apps/myapp? This is Solaris 10 sudo. Thank you for your reply, but I don't need wildcards for the path to the commands, but wildcards for the arguments for the commands. For example, we want to do something like... sudo mycmd /opt/userarea/area1 sudo mycmd /opt/userarea/area1/area2 sudo mycmd /opt/userarea/area1/area2/area3 So far, using wildcards for the arguments in sudoers look like this: /opt/userarea/* /opt/userarea/*/* And it seems like if we want to have N levels of directories, then we need N lines in sudoers! Is there a better way to include all N levels in one line in sudoers? Thanks.

    Read the article

  • hardening a server: disallow password-login for sudoers and log unusual ips

    - by Fabian Zeindl
    Two question regarding sudo-login into an ubuntu-system (debian tips welcome as well): Is it possible to require sudoers on my box to only login with publickey-authentication? Is it possible to log which ip sudoers log in from and check that for "unusual activity" or take actions? I'm thinking about temporarily removing sudo-rights if sudoers don't log in from whitelisted IPs. Or is that too risky to be exploited?

    Read the article

  • Make sudoers work with only certain parameter?

    - by Evan
    I'm trying to make my sudoers file allow a user to adjust the backlight without having to enter in the password. This is what I have: # User alias specification Cmnd_Alias ADJBL = /usr/bin/su -c "echo 150 >/sys/class/backlight/intel_backlight/brightness" # For our user.. ouruser HOME=(root) NOPASSWD:ADJBL .. but it doesn't seem to be working, I still get prompted for the password when I try and run that command with sudo. Apparently there is something I'm missing here, any ideas?

    Read the article

1 2 3 4 5 6 7  | Next Page >