I have on my Ubuntu 16.04 VM in /etc/sudoers.d/waagent the configuration that is unwanted. Even if I log as root, root has only read permission.
How should I safely edit configuration for Azure waagent?
I wanna change
someuser ALL=(ALL) NOPASSWD:ALL
to
someuser ALL=(ALL) ALL
Can I simply add write permission for root and edit the file or need I do it in different way via Azure commands?
I would like to prevent the case when sudo configuration is damaged due fact I have no physical access to VM and cannot fix it.
For your issue, I think there is no more safe way to edit the /etc/sudoers.d/waagent(in my side, the file name is /etc/sudoers.d/90-cloud-init-users). The file just can be edited with the root permission. If you use the root to edit then everything works in the same way.
So I suggest you can just use the root user, add the write permission and edit the file as you want. But do not forget to change the permission back, in other words, remove the write permission when everything is OK.
Short answer:
Use visudo -f /etc/sudoers.d/waagent
Long answer:
When editing sudoers files, always use visudo. It is a vi editor, but includes built-in checks to prevent you from corrupting the file and will allow you to save the file even though there's no write permissions on the file (assuming you run it as root). Changing the permissions on the file to allow write access and using a normal text editor is a bad idea. Too easy to forget to change it back and one misplaced symbol or misspelled word can corrupt the file. That's why there is no write permission by default - to act as a check to prevent unwanted modifications that could potentially render your system unusable.
Related
I am running a default t2.nano ec2 linux ami. Nothing is changed on it. I am trying to rsync my local changes to the server. There is a permissions issue that I don't know enough about to fix.
My structure is as follows. I'm trying to push my work to the technology directory. The technology directory is mapped to a staging domain. i.e. technology.staging.com
:/var/www/html/technology
this is from the root, and it does work fine, it's the rsync that is failing.
when I push locally to that directory I get a "failed: Permission denied (13)" error.
I'm running an nginx server and assigned permissions to the www directory as follows:
sudo chown -R nginx:nginx /var/www
My user is ec2-user which is the normal default. Here is where I am tripped up. You can see the var directory is given root access.
You can see that the www directory then has permissions set to nginx so our server can access the files. I believe I need to add the ec2-user to this directory as well as the nginx user so that I can rsync my files there and the server will still have access I'm just unsure of how to do that.
As a test, I created a test directory at this location and it worked successfully.
:/home/ec2-user/test
you can see the permission here are set for the ec2-user which is why it works i'm sure.
Here's the command I'm running on my local machine to rsync my files which fails.
rsync -azP -e "ssh -i /Users/username/devwork/company/comp.pem" company_technology/ ec2-user#1.2.3.4:/var/www/html/technology
Here's the command that was working.
rsync -azP -e "ssh -i /Users/username/devwork/company/comp.pem" company_technology/ ec2-user#1.2.3.4:/home/ec2-user/test
I have done enough research and testing to know that it's a permissions error, I just can't figure out the right way to solve it. Do I need to create a group and assign both the nginx and ec2-user to the group and then give that group the same permissions level on the :/var directory.
Side note, what permissions level do I set for the chown to make these permissions that are currently set?
I have server config files in the :/etc/nginx/conf.d/ directory that map to the directories I create inside of :/var/www/html directory so I can have multiple sites hosted on the server.
So in this example, I have a config file at :/etc/nginx/conf.d/technology.conf which maps to the directory at :/var/www/html/technology
Thank you in advance, again, I do feel like I have put forth the research and effort to show that I've gone as far as I know how to do.
The answer made sense after I spent roughly a day playing around. You have to give access to both the ec2-user and the nginx group. I believe you never want to put a user in a group that involves the server itself, I think things would go south.
After changing the owner to both the ec2-user and nginx group, it still didn't work exactly the way I wanted it to. The reason was, I needed the nginx permissions to be updated to what they had when they were assigned the user role.
Basically, theec2-user had write permissions and the server did not. we wanted the user to have write permissions so they could rsync my local files to the directory on the server, and the nginx group needed the same level of permissions to display the pages. Now that I think about it, the nginx group may have only needed read permissions to display things, but this at least solved the problem for now.
Here is the command I ran on the server to update the ownership and the permissions, as well as the output.
modify ownership
sudo chown -R ec2-user:nginx :/var/www/html/technology
modify permissions
sudo chmod -R o=rwx,g+rwx,o-w technology
The end result looks like this
You can see the permissions match, and the ownership is as we expected. The only thing I have to figure out is after I rsync new files to the server, I need to run the previous code to update the permissions again. I'm sure that will come to me later, but I hope this helps anyone in the same situation.
I have a freeradius server setup with google authenticator to provide a basic working multi-factor setup.
Everything works when I run radiusd in debug mode as root. If I start it as a service, logons fail and this messages is recorded when processing messages:
radiusd(pam_google_authenticator)[1115]: Failed to read "/home/user#domain.com/.google_authenticator" for "user#domain.com"
I think this must be a permissions issue since it works fine when run as root.
I don't really want to edit the permissions on each secret file for every user.
I have tried specifying root in
/etc/raddb/radiusd.conf
user = root group = root
but still the service fails unless run from the command line as root. Does anyone have a nice elegant solution to this conundrum?
I think you should check out your systemd service file for radiusd. It might look something like:
https://github.com/ipfire/ipfire-3.x/blob/master/freeradius/systemd/freeradius.service
You can add User= and Group= in the [Service] section of the .service file if needed. See
https://unix.stackexchange.com/questions/347358/how-to-change-service-user-in-centos-7
and
https://serverfault.com/questions/806617/configuring-systemd-service-to-run-with-root-access
It would be a good idea to put the contents of the .service file for radiusd in your post.
I gave the www group write permissions to a file but Apache still doesn't have write permissions to that file. However, if I give 'Others' write permission to that file (e.g. 0777 permission) Apache gets write permission to that file.
How can I fix this?
I am using Amazon Linux hosted by Amazon EC2.
There could be a lot of reasons for that...
Did you try to setenforce 0?
What if chmod o+w to that file?
Try that first, it will dismiss first guesses and common problems.
I'm trying to get my php cgi processes to read from a file on my filesystem. Both the file and parent folder have all rwx permissions allowed and the file has the same owner and group id as the php processes, www-data.
No matter how I try to open the file (read(), file_get_contents(), stream_get_contents()) I always get the same error:
failed to open stream: Permission denied
I have no problem opening the file in the php interactive session, using cat on the command line, or with python.
What is going on?
I've seen this problem before on Linux systems with SELinux enabled. The httpd process is typically given its own security context that only allows certain files to be accessed.
You can check to see if SELinux is enabled by running ls --scontext on the file and on the php script. If the two files have the same context or if ls complains about the argument then SELinux is probably not the cause of the problem.
Assuming SELinux is the cause of problem then you could try setting the file in question to have the same security context as your php script with the chcon command. For example:
chcon --reference=/var/www/html/page.php /data/filetoread
where /var/www/html/page.php is your php script and /data/filetoread is the file that you want to access.
It turns out this file was under a FUSE filesystem which had not been mounted with the allow_other option.
For some tests I'm doing, I'm required to remotely tail the apache access log via ssh. I can successfully do that only when the permissions are accurately set for the log. I've noticed that once a week, a new apache access.log is created and the permissions are reset.
My current work around is editing the permissions on the log once a week:
chmod 644 /var/log/apache2/access.log
I was wondering if there was a more permanent solution such as extending the time that the old log remains or automatically setting permissions when the new log is created.
If it matters, I'm running the server on Ubuntu 11.10
Edit your logrotate.conf file to set the correct owner/permissions for the apache.log file. Something like this:
/var/log/apache2/access.log {
weekly
create 0644 root utmp
rotate 1
}
(Edit: Changed mode from 0744 to 0644. No need to set the execute bit.)
Maybe another application, like logrotate, is altering the logs? (Sounds like it, as it only happens weekly) I don't think Apache itself is responsible for the permissions chance.
A good place to start is check /etc/cron./* to see if any cron jobs are touching the access.log
Good luck!