I'm using Ubuntu 12.04. By default /var/log/syslog is readable only by adm group members.
$ls -lh /var/log/syslog
-rw-r----- 1 syslog adm 23M Oct 29 10:20 /var/log/syslog
I tried using dmesg -f syslog, but it is also not working.
Thanks in advance for your help.
You can change the output directory in the syslog.conf, but I don't think you can change the group:owner. If you install syslog-ng, you can set the global options to output files with whatever rights you require.
create_dirs(yes);
dir_group("root");
dir_owner("adm");
dir_perm(0755);
Related
We are getting the error "permission denied" when trying to write to a file that is owned by a service user and a shared group. In particular that is www-data:www-data and the user trying to write to it is in the group www-data.
There is no acl on none of the parent folders and the permissions to the file and folders are correct.
Here some details:
$ sudo -u deploy id -Gn
www-data
$ ls -lah /tmp
drwxrwxrwt 17 root root 4.0K Jul 11 11:22 .
drwxr-xr-x 23 root root 4.0K Jul 8 10:08 ..
...
-rw-rw-r-- 1 www-data www-data 0 Jul 11 10:50 test
...
$ echo 'hello world' | sudo -u deploy tee -a /tmp/test
tee: /tmp/test: Permission denied
hello world
we tried that on different folders and made sure there is no acl on any of the folders or parents or files...
Unfortunately that is not described in the link stark posted in the comment. And also not in any other page I found until I found an answer here on stackoverflow that clarified it.
2018 two new filesystem configurations got added to sysctl that should prevent regular files and fifos from beeing opened with the O_CREAT flag (as append mode is doing) in directories with the sticky bit set unless the user is the owner of the file. This commit added the settings: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30aba6656f61ed44cba445a3c0d38b296fa9e8f5
To change that behaviour you have to set fs.protected_regular to 0:
sudo sysctl fs.protected_regular=0
Or to persist the change add fs.protected_regular=0 to your sysctl.conf.
side node: since O_CREAT is not deleting or renaming the file I'm wondered why it is connected to the sticky bit. It really is possible to create a file in directories with the stick bit set.
I am trying to use rsync to backup some data from one computer (PopOS! 21.04) to another (Rocky 8.4). But no matter which flags I use with rsync, file permissions and ownership never seem to be saved.
What I do, is run this command locally on PopOS:
sudo rsync -avz /home/user1/test/ root#192.168.10.11:/root/ttt/
And the result I get something link this:
[root#rocky_clone0 ~]# ls -ld ttt/
drwxrwxr-x. 2 user23 user23 32 Dec 17 2021 ttt/
[root#rocky_clone0 ~]# ls -l ttt/
total 8
-rw-rw-r--. 1 user23 user23 57 Dec 17 2021 test1
-rw-rw-r--. 1 user23 user23 29 Dec 17 2021 test2
So all the file ownership change to user23, which is the only regular user on Rocky. I don't understand how this happens, with rsync I am connecting to root on the remote host, but as the result files are copied as user23. Why isn't -a flag work properly in this case?
I have also tried these flags:
sudo rsync -avz --rsync-path="sudo -u user23 rsync -a" /home/user1/test root#192.168.10.11:/home/user23/rrr
This command couldn't copy to the root directory, so I had to change the remote destination to user23's home folder. But the result is the same.
If someone could explain to me what am I doing wrong, and how to backup files with rsync so that permissions and ownership stay the same as on the local computer I would very much appreciate it.
Have a look at how the (target)filesystem is mounted on the Rocky(target) system.
Some mounted filesystems (such as many FUSE mounts) do not support the classical unix permissions, and simply use the name of the user who mounted the filesystem as owner/group.
Any attempt to chown/chmod/etc (either by you or by rsync) will just silently be ignored, but appear to "succeed" (no errors reported).
when I run
sudo service logstash start
it doesn't write anything to /var/log/logstash/logstash.log
Not really that good at unix, is there anything I am missing to make it write to the log?
I've installed logstash the yum way, as detailed in the logstash website
ls -l logstash
-rw-r--r-- 1 logstash logstash 80949 Aug 11 09:16 gc.log
-rw-r--r-- 1 root root 0 Aug 11 09:15 logstash.err
-rw-r--r-- 1 root root 0 Aug 11 06:17 logstash.log
-rw-r--r-- 1 root root 60 Aug 11 09:15 logstash.stdout
Logstash can't write log info because the owner of the log file is root currently.
You should change owner of the log file with the command below
chown logstash:logstash logstash.log
I assume that the reason is you started logstash as root user in contrast with logstash service is started as logstash
(See the contents of this file /etc/init.d/logstash)
It seems logstash is writing log into gc.log. you can change the file instead.
Have you change the /etc/init.d/logstash file before?
in the file, you can find name field.
if the value of the name is logstash, the log file name will be logstash.log
if you want to change the log file name, modify /etc/init.d/logstash and change the value of the name to "logstash" (I assume that your current value is "gc")
name=logstash
pidfile="/var/run/$name.pid"
LS_USER=logstash
LS_GROUP=logstash
LS_HOME=/var/lib/logstash
LS_HEAP_SIZE="1g"
LS_LOG_DIR=/var/log/logstash
LS_LOG_FILE="${LS_LOG_DIR}/$name.log"
LS_CONF_DIR=/etc/logstash/conf.d
LS_OPEN_FILES=16384
I have a file server based on Ubuntu 14.04. Many users do exist in it where each user belongs to its own group (such as lucas:lucas) but also to a common group called "sambashared".
lucas#arturito:~$ cat /etc/group | grep lucas
adm:x:4:lucas,syslog
lp:x:7:saned,lucas
cdrom:x:24:lucas
sudo:x:27:lucas
dip:x:30:lucas
plugdev:x:46:lucas
lucas:x:1000:
lpadmin:x:111:lucas
sambashare:x:112:lucas
There is also a shared folder under the /home: /home/share. Such a folder has the SGID bit enabled, so files created under it will belong to the "sambashare" group:
lucas#arturito:/home$ ls -l | grep samba
drwxrwsr-x 10 share sambashare 4096 Apr 24 13:44 share
lucas#arturito:/home/share$ touch test.text
lucas#arturito:/home/share$ ls -l test.text
-rw-rw-r-- 1 lucas sambashare 0 Apr 24 14:02 test.text
So, as seen before, the files being created under /home/share are created fine (lucas:sambashare). The issue I'm having is for files being created on a deeper subfolder of /home/share:
lucas#arturito:/home/share/99_varios$ touch file.txt
lucas#arturito:/home/share/99_varios$ ls -l | grep file.txt
-rw-rw-r-- 1 lucas lucas 0 Apr 24 14:19 file.txt
If you see before, the file file.txt belongs to lucas:lucas, but I was hoping it to be lucas:sambashare.
Any idea on how to solve this? Or, is it solvable?
Thanks in advance,
Lucas
Possible workaround is to use facl (file access control lists).
setfacl -m default:group:sambashare:rw /home/samba
All new files in /home/samba and its sub-folders will be owned by lucas:lucas but sambashare group will have read and write permission.
More in getfact (1) and setfact (1).
I have a directory cyanspring with a nohup.out file.
drwxr-xr-x 12 usr1 usr1 4096 Aug 20 13:59 cyanspring
Owner of the file is able to read it:
[root#lw414 usr1]# sudo -u usr1 ls -l cyanspring/nohup.out
-rw-r--r-- 1 usr1 usr1 30617 Aug 20 14:00 cyanspring/nohup.out
When I try to read it with another user, I get Permission denied.
[root#lw414 usr1]# sudo -u zabbix ls -l cyanspring/nohup.out
ls: cannot access cyanspring/nohup.out: Permission denied
If i go inside the directory, I am able to read the file with the same user who had "Permission Denied".
[root#lw414 usr1]# cd cyanspring
[root#lw414 cyanspring]# sudo -u zabbix ls -l nohup.out
-rw-r--r-- 1 usr1 usr1 30617 Aug 20 14:00 nohup.out
Absolute path doesn`t work as well.
I thought it doesn`t matter where you try to access the file from as long as you have the link and permissions. Can anybody give me a hint where I am wrong? Could it be because of outer folders permissions?
You got "Permission denied" because user zabbix does not have search permission to lachesis directory.
This can be fixed by starting this command from lachesis directory:
sudo chmod go+x .
Permissions are calculated for each directory beginning from current directory if you give relative path, or beginning from root, if you give absolute path.