Deny access to a specific folder for a sudo user - bash

I have a question: I am root in an Ubuntu system. I want to give a user (say username is X) permission to execute any command but at the same time I have a folder that I want no one to be able to access except my user (which is certainly not X because it is say Admin) or root. Any suggestions? Thanks!

If a user can execute any commands as sudo he can also become root whenever he wants. That's why there is not a chance to protect a directory from browsing by such a user unless you restrict the list of commands the user can execute with sudo.
One idea could be to put the folder on a separate partition which is encrypted with a password. The user would need to decrypt the partition before he could mount that folder.

Related

How can I get the name of the user that has logged into Oracle/Set up ssh to not need a username?

I'm writing a script that will scp some files without requiring a password from my local database to a remote database. Currently, I've set up ssh (following these directions: http://www.linuxproblem.org/art_9.html) and I'm able to use
scp /home/oracle/sendfiles/* myUsername#remoteServer:/home/oracle/receivefiles/
To send files over. However, this requires my script to have myUsername hard-coded for it to work. I'd like to be able to run
scp /home/oracle/sendfiles/* remoteServer:/home/oracle/receivefiles/
So that other users can use my script without having to specify their username. Is there a different way to set up ssh so I don't need to specify a username? Right now when I run my script without specifying my username it prompts me for oracle#remoteServer's password.
At the moment you seem to have run ssh-keygen as oracle on your local server, but added the contents of the locally-generated /home/oracle/.ssh/id_rsa.pub file to your own authorized_keys file - i.e. /home/myUsername/.ssh/authorized_keys - on the remote server.
From context I suspect you, and other users, log in to your local and remote boxes under your own accounts and then su to the oracle account. With the way you've set up the keys, any local user who can get to the oracle account on the local server now has access to your personal account on the remote server - which is not what you intended.
And although your first command specifying the remote user name works, the files on the remote end will be owned by you rather than oracle; which means the target directory /home/oracle/receivefiles/ must be at least group- and possibly world-writable. That may not be necessary, and generally isn't a good idea - opinions vary but home directories tend to be locked down as tightly as possible, particularly for sensitive accounts like that one. (You don't want someone who gains access to the server with low privs to be able to do something nasty by, say, editing Oracle's .profile or creating some new dot file which, for instance, deletes all the DB data files next time someone logs into that account...)
The contents of id_rsa.pub need to be added to /home/oracle/.ssh/authorized_keys on the remote server (and should be removed from /home/myUsername/.ssh/authorized_keys!). Once you've done that, you and anyone else that has su'd to oracle on the local server will be able to do:
scp -p /home/oracle/sendfiles/* remoteServer:/home/oracle/receivefiles/
without being prompted for a password, and the files at the remote end will be owned by oracle instead of you. (The -p flag means permissions and timestamps will be preserved too.)

Forcing user created folders and files to inherit a specific parent folder's groups in macOS

I have multiple users accessing a file system and I need to make sure each time they create a folder it inherits the groups and permissions of the parent folder. Currently each time they create a folder or upload a file the file or folder's group defaults to that user's default group.
Some of these parent folders have multiple groups assigned to them.
Without changing the default group assigned to the user I need to make sure that any folders/files created/uploaded to the system inherit the group(s) of the parent folder.
I have been playing with:
chown
chgrp
chmod -R +a "g:somegroup allow list,file_inherit,directory_inherit,...,..." /file/path
chmod g+s /file/path
But it has not solved the problem. When the users create folders and upload files they are associated with that user's default group.
The issue with this is that if bob creates a folder and then joe tried to use it, joe does not have permission to write in that folder because the default group associated to bob does not have chmod 775 permissions.
That means the folder is only accessible by the owner.
Hoping to have lots of different groups built into the file system for siloing different clients, users, etc with many people having access to everything, so I can't change every user's default group. I need to be able to just add them to the groups they are supposed to be able to write to.
Suggestions?
We are also having this issue on a brand new iMac running High Sierra. It is killing us. I noticed no one answered but I am hoping maybe you found a solution.
Debbie

why jenkins create a new user named 'Jenkins' when install jenkins on osx and i don't know the password

install jenkins in mackbook pro and success.
but I don't know why jenkins create a new user named 'Jenkins',
and I don't know this user's password,
how to get this password and can I delete this user??
OS X software frequently creates special users to do specific tasks. By running as its own user, it prevents that software from accessing or modifying your own private files inadvertently, and also prevents users from accidentally modifying that software's private data files.
Note that those sorts of user accounts usually are not login users—that is, they typically do not have a password, because you can't log in as that user. Instead, the software starts out running as the root user (superuser) and then reduces its privileges to those of the non-login user account.

localhost on a Mac, mySQL Root, write enabling folders, and migrating to a real server

I'm developing a site on an XAMPP localhost on a Mac. I manipulate my mySQL database via phpMyAdmin (not comfortable with the command line).
Everything works fine (I know, right!).
2 things have got me worried for when I eventually move my site to a real online live server.
First the background:
1) I am using a CMS/Framework type thing. When trying to install it (in the htdocs folder), I found that I needed to write-enable some folder or the other (FileSystem permissions in Finder). So I write-enabled all the folders contained in the mother folder. Mac's have 3 default types of users (right-click a folder in Finder and choose info). They are "Me", "admin" and "everyone". I right-clicked the mother folder (in Finder), selected "Read&Write" for all 3 types of users, and chose "Apply to enclosed items." And the installation worked out fine.
2) I am able to come and go as I please into phpMyAdmin to directly manipulate my database. I presume phpMyAdmin recognizes me as Root. I do not have a password for Root. I do have a separate user created with a password (let's call the user "specificdbuser") and I use "specificdbuser" to connect to the database from within my site's PHP code.
My concerns regarding 1 & 2 are:
1) I'm presuming that enabling Read&Write permissions for all 3 types of users, and in particular for all folders and items within the mother folder, is a security risk. Is there a better way? (a) How do I figure out which folders need to be writeable so that I only make those writeable instead of making everything writeable?, and (b) Instead of giving Read&Write permissions to the 3 default Mac user types, should I instead be creating some new type of user (Root? specificdbuser?) and only give that user permission to Read&Write permissions? As this is a website, do I need to give "everyone" permission to Read&Write? What the heck does "everyone" mean anyway?
2) Let's say I eventually set up my database's Root account with a password. When I eventually migrate my localhost site to a real live online server, will this Root / password combination work on that site too?
I'm kind of confused, are you talking about FileSystem permissions or MySQL Database permission? If it is a FileSystem question, then please check the web service user that runs your PHP scripts. If it's a database permission, then please refer to #2 answer.
I would say, for security reason never use the "root" when connecting to your database. I would suggest you setup the same user name/password/permissions on your local and in server. But if that doesn't make sense you can have a config file that says if "localhost" then db_user = blah_blah, else if server side db_user = blah.

Apache 2 on Mac - localhost requires authentication

I'm using Apache 2 to run my localhost on Mac (Mavericks), and every time I add a file or a folder in the default directory /Library/WebServer/Documents (and its subdirectories) the system asks me to authenticate:
This is a problem specially when using frameworks like Symfony or Zend Framework because they can't have writing access to folders. What can I do to solve this?
Mac/Linux grants access on different levels:
Per user
Per group
Per everybody
The folder Library/WebServer/Documents outside of the logged-in user paradigm (you) therefore write access (and other access like execute) is only granted to the administrator of the computer (or so-called root) which isn't you however on most Mac environment the password of root is your password (different users with the same password).
You will want to modify Apache2 configuration and change the directory to a folder located within your user's directory which is something like /Users/{whatever is your username} (you will probably need to create the folder).
Once, you moved the content of /Library/WebServer/Documents into the new folder, make sure the permission are set properly. Refer to the following documentation at the chapter "How to Modify Permissions with the Info Window".
The reason why your Mac is asking for permissions to write files outside of your user's directory is for security reasons. Imagine if you download a file, execute it and grant access (by giving the root password) then the file could potentially be a virus and erase or do all kind of things on your computer.

Resources