The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

chown

Discussion in 'General Discussion' started by nw1, Oct 19, 2009.

  1. nw1

    nw1 Member

    Joined:
    Dec 13, 2006
    Messages:
    5
    Likes Received:
    0
    Trophy Points:
    1
    hello

    If i let permission in chown and touch comands in 0700 root:root can have error in cpbackup cpanel performed at every night?


    Thanks
     
  2. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,446
    Likes Received:
    195
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Could you please rephrase that question another way or expand on the explaination/problem a bit more?
     
  3. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    No, you shouldn't break anything setting chown and touch to 0700 assuming of course you are running a standard system and don't have additional custom scripts or processes calling those out of the ordinary!

    (Though you can do 0700, that may be excessively tight for this purpose just a bit)

    That is actually close to how I setup systems by default normally as chown, not to be confused with chmod, really should not be run by any user other than root anyway and touch is too far often abused by hackers as a tool to help cover the trails left behind.

    Perhaps something more like this >
    Code:
    # chown root:root /bin/chown /bin/touch /usr/bin/chattr
    # chmod 0754 /bin/chown /bin/touch /usr/bin/chattr
    # chattr +i /bin/chown /bin/touch /usr/bin/chattr
    
    This way only root can execute those commands but also helps prevent throwing some errors you might encounter if it is totally inaccessible by non-root users.

    Obviously that's not an "all inclusive list" of commands that should be locked down but it is definitely a good start.


    NOTE: You were very wise in asking first because it is very possible to break your system and processes if you lock down the wrong commands or put the permissions too tight on some things but the above commands should be perfectly fine. ;)
     
    #3 Spiral, Oct 19, 2009
    Last edited: Oct 21, 2009
  4. nw1

    nw1 Member

    Joined:
    Dec 13, 2006
    Messages:
    5
    Likes Received:
    0
    Trophy Points:
    1
    hello Thanks for the answer , please and about this commands, will be break a something in cpanel (backups) ? and the system ?

    1)/usr/bin/perl chmod 754 user lost cgi

    2)chmod 754 /bin/bash user lost bash ( example perl exec ("bin/sh 1.sh"))

    3)/bin/sed chmod 754 and /bin/grep chmod 754

    i´m blocking execute in this commands for script in web.

    Thanks
     
  5. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    No, don't do that! That will very much break your system!

    Do not restrict any of the above commands unless you want to seriously break a large number of scripts all across your server!

    bash - you are out of your mind locking that down! ;)

    (I wouldn't allow users to have that as their shell but don't touch permissions unless you want to break the server very bad)

    perl, chmod, grep, and sed are all used by many, many scripts and that includes a great many "non-root" scripts!

    You CAN restrict touch, chown, and chattr safe enough but don't touch bash, perl, chmod, grep, and sed --- bad, bad idea!

    If you are looking for other to lock down, you might look at /usr/bin/wget and /usr/bin/lynx which both can usually be set to 0750 if ownership is "root:cpanel" without blowing away the server scripts though you may interfere with regular user cronjobs or scripts but that could be what you are intending in this case ;)

    Wrong way of going about this ...

    Disable functions in your languages that make system calls, use SuPHP for your PHP, monitor your logs.

    For PHP, you might look into some of these and can back off per user as needed:
    Code:
    disable_functions = "apache_child_terminate, apache_get_modules, apache_get_version, apache_getenv, apache_note, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, ini_set, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode, dba_replace, ftok, posix_access, symlink, disk_free_space, show_source, disk_free_space, diskfreespace, phpinfo"
    
     
    #5 Spiral, Oct 20, 2009
    Last edited: Oct 21, 2009
  6. cPanelDon

    cPanelDon cPanel Quality Assurance Analyst
    Staff Member

    Joined:
    Nov 5, 2008
    Messages:
    2,557
    Likes Received:
    7
    Trophy Points:
    38
    Location:
    Houston, Texas, U.S.A.
    cPanel Access Level:
    DataCenter Provider
    Twitter:
    To avoid certain errors you should ensure that files within user accounts are, at a minimum, readable by the user of that account. If the file is changed to an ownership of "root:root" and access permissions (chmod) 0700, then it is likely the user will not be able to read the file and this may trigger an error during the cpbackup process for that user account.
     
Loading...

Share This Page