When creating an auditd rule in Linux, what is the behaviour if no permissions are specified?
ie
-w /etc/shadow -p wa -k shadow
will monitor for new writes or changed attributes.
But if I wrote it as:
-w /etc/shadow -k shadow
then is there a default permission? or does it imply that all permissions will be monitored ie rwax?
Without -p:
The -w option tells audit to add a watch to the file specified, in this case /etc/shadow. All system calls requesting access permissions to this file are analyzed
https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-audit-comp.html#sec-audit-rules
Using -p:
This rule adds a watch to the /etc directory and applies permission filtering for read and execute access to this directory (-p rx). Any system call requesting any of these two permissions is analyzed.
Related
I have a program called HelloWorld belonging to user test
HelloWorld will create a file HelloWorld.pid in /var/run to keep single instance.
I using following command to try to make test can access /var/run
usermod -a -G root test
However, when I run it, falied
could someone help me?
What are the permissions on /var/run? On my system, /var/run is rwxr-xr-x, which means only the user root can write to it. The permissions do not allow write access by members of the root group.
The normal way of handling this is by creating a subdirectory of /var/run that is owned by the user under which you'll be running your service. E.g.,
sudo mkdir /var/run/helloworld
sudo chown myusername /var/run/helloworld
Note that /var/run is often an ephemeral filesystem that disappears when your system reboots. If you would like your target directory to be created automatically when the system boots you can do that using the systemd tmpfiles service.
Some linux systems store per-user runtime files in /var/run/user/UID/.
In this case you can create your pid file in /var/run/user/$(id -u test)/HelloWorld.pid.
Alternatively just use /tmp.
You may want to use the user's name as a prefix to the pid filename to avoid collision with other users, for instance /tmp/test-HelloWorld.pid.
Is it possible avoid sudo word while executing the higher privileged commands to a non-root user via a sudo policy such non-root users should not be able to know that he is executing higher privileged commands and also the usage of sudo might be complex.
Example:
Normal Execution of Sudo Command.
$ sudo -u root /usr/bin/tcpdump
non-root users should execute tcpdump like below.
$ tcpdump
Thanks in advance.
Note: I have defined a Sudo Policy for non-root users. So, when a non-root user executes tcpdump, in the backend it should execute as
sudo -u root tcpdump.
Yes. It is possible.
You should:
1- Create a new specific new group where some users would belong:
groupadd nonroot
2- Add your privileged users to that group:
2.1- Edit /etc/group:
vim /etc/group
2.2- Find the line of new created group. It should look like that:
nonroot:x:127:
2.3- At the end, add your privilaged users:
nonroot:x:127:user1,user2
3- Change the group of your binary:
chgrp nonroot /usr/bin/tcpdump
4- Give group execution permissions to the binary:
chmod g+x /usr/bin/tcpdump
You have to have in count that if the binary reads, writes or executes files which user1 has no permissions, you'll have modify them in the same way.
If you cannot change the group of the binary, check the right answer of post bellow, which is a similar way:
Allow users of a certain group to run a command without sudo
Hope it helps.
NOTE: Commands may differ between different linux/unix distros.
I can see at least two possibilities:
Wrap it in a script (an alias is also possible, but if users can use different shells or just start them manually, it can turn into a maintenence hell)
Set the suid bit on tcpdump, but that means everyone who can invoke tcpdump always does so as the owner.
You might want to explore using sudoers file.
Using CentOS as an example (should be similar for Debian), create a file within sudoers.d with the relevant name, e.g. tcpdump and include the following:
user ALL=NOPASSWD: /usr/bin/tcpdump command
Replace the user and command to suit your purpose. You can find out more here.
This coupled with a alias tcpdump='sudo tcpdump for the user should fit your use case.
I followed this link to change group/user permission to add my self to www-data group
but I am still unable to edit contents in /var/www , specially with uploaded content.
This is my development environments , I dont want to go to chmod /var/www/ each time there is an upload.
While keeping contents under /var/www what are the steps to change /var/www directory permissions to able to edit contents directly from and an IDE
My login account user and group name is debianaut:
groups www-data
www-data : www-data debianaut
groups debianaut
debianaut : debianaut www-data
I login/out after making these changes. It seems straight forward that if I am user of cretain group I should get whatever permissions they hold .
please help resolve this issue
I suspect your issue is the fact that the user account has more than one group, and the default group is not the one with write permission to that folder.
While Linux allows your user access to multiple groups, it does not provide access to all of them at once. Here are some options to address this:
Change the group used while running in a shell
Change the user's default logon group
Use ACLs
New Group in a Shell
In order to operate as a different user after starting a shell, use newgrp.
Change default Group
In order to change the user's default group, edit /etc/passwd, or use a command to do the job (not sure which command, and it probably differs from distribution to distribution).
ACLs
You will likely prefer to use ACLs. See the man pages for setfacl and getfacl. ACLs (access control lists) are expanded permissions. Not all Linux systems support them, but I would be surprised if your Debian system doesn't. The following should add read-write-execute permission for user debianaut to all of /var/www:
setfacl -R -m u:debianaut:rwx /var/www
By the way - you can check the group id of a running process (such as your IDE), use ps -o gid -p <pid>.
Inheriting ACLs
Following the post here lead to the answer for inheriting ACLs.
The answer is called default ACLs in the man page. The following will set the ACL for denianaut as the default for files created in /var/www:
setfacl -R -d -m u:debianaut:rwx /var/www
I think you should change your umask to 0002:
umask 0002
This could also be useful.
For me the problem has to do with joomla configuration. You need to change the default permissions for uploaded files. This link may help you: http://forum.joomla.org/viewtopic.php?t=286584
There are two relatively simple options, none of them should involve www-data -- you don't want the webserver to have unnecessary write access to your contents.
1) Just take ownershop of /var/www for your userid that will edit the files.
2) Establish a new group, make it one of your secondary groups, and make /var/www group-writable + setgid (chmod g+s) that new group. New files in the setgid dir will have their group set to the shared group.
I am using Cygwin and trying to change the group access permission with chmod, e.g.
$ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
$ chmod g= id_rsa
$ ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
But this does not work. I can change permission for user and others. Seems that the permission level for group somehow keeps the same as that of user?
I was having a similar problem to you, and I was using the NTFS filesystem, so Keith Thompson's answer didn't solve it for me.
I changed the file's group owner to the Users group:
chown :Users filename
After doing that I was able to change the group permissions to my will using chmod. In my case, since it was an RSA key for OpenSSH, I did:
chmod 700 filename
And it worked. In Cygwin you get two groups by default, the Root group and the Users group. I wanted to add another group, but I wasn't able to do it with the tools I'm used to use on Linux. For that reason I just used the Users group.
Cygwin doesn't like files to be owned by groups that it doesn't know.
Unfortunately, that happens quite often in Cygwin, especially if your PC is in a Windows domain where things keep changing.
I also synchronise my files between two PCs, via an external drive, and the uids/gids are different between the different PCs, so this is a source of problems.
If you do ls -l and see a numeric group id instead of a group name, it means Cygwin doesn't know the gid - i.e. it's not in /etc/group, and Cygwin can't query it from Windows either. You can confirm this by running getent group <gid>, where <gid> is the numeric group id.
To fix it, you can either use chgrp to change the group for all affected files/directories, as described in the accepted answer above, or create an entry for the unknown gid in /etc/group, with any unused group name (e.g. Users2).
After doing this, it may be necessary to close all of your Cygwin windows and then re-open them.
An experiment shows that chmod does work correctly to change group permissions under Cygwin.
The experiment used a file on an NTFS partition. Cygwin implements a POSIX layer on top of Windows, but it still ultimately uses the features of Windows itself, and of the particular filesystem implementation.
On modern versions of Windows, most hard drives are formatted to use NTFS, which provides enough support for chmod. But external USB drives typically use FAT32, which doesn't have the same abilities to represent permissions. The Cygwin layer fakes POSIX semantics as well as it can, but there's only so much it can do.
Try
$ df -T .
If it indicates that you're using a FAT32 filesystem, that's probably the problem. The solution would be to store the file on an NTFS filesystem instead. A file named id_dsa is probably an SSH private key, and it needs to be stored in $HOME/.ssh anyway.
Is your home directory on a FAT32 partition? As I recall, recent versions of Windows ("recent" meaning the last 10 or more years) are able to convert FAT32 filesystems to NTFS.
The remainder of this answer was in response to the original version of the question, which had a typo in the chmod command.
Cygwin uses the GNU Coreutils version of chmod. This,
chmod g=0 fileName
is not the correct syntax. I get:
$ chmod g=0 fileName
chmod: invalid mode: `g=0'
Try `chmod --help' for more information.
(This is on Linux, not Cygwin, but it should be the same.)
To turn off all group permissions, this should work:
$ chmod g= fileName
$ ls -l fileName
-rw----r-- 1 kst kst 0 Jun 13 10:31 fileName
To see the chmod documentation:
$ info coreutils chmod
To see the documentation on symbolic file mode:
$ info coreutils Symbolic
The format of symbolic modes is:
[ugoa...][+-=]PERMS...[,...]
where PERMS is either zero or more letters from the set 'rwxXst', or a
single letter from the set 'ugo'.
Like previous answers, not recognized groups cause such issues. It mostly happens in Windows Domains.
The easiest way to fix it is regenerate your /etc/passwd and /etc/group files (parameter -d is needed for domain users):
mkpasswd -l -d > /etc/passwd
mkgroup -l -d > /etc/group
Close and launch Cygwin again.
This is a very annoying issue for me. In my case user135348's solution worked best. The biggest issue with the chown :Users -R approach is that every time a new file is created, it will be assigned to the unknown gid 1049120. It's very frustrating to keep changing file gid.
I tried mkgroup too, but in my case it didn't work: My gid is 1049120.
Based on the rules explained in Mapping Windows SIDs to POSIX uid/gid values : : 0x100000 offset is used for account from the machine's primary domain.
Trying to remove the same offset from 1049120, you get 544, which is built-in Administrators group's RID.
This account is not a member of the local Administrators group; we use SuRun to grant administrator rights without giving out credentials. In this case, mkgroup failed to generate all the possible gids.
Editing the group file and adding a customized group name seems always to fix the issue easily.
I had this issue when working remotely from the Domain and using cygserver.
Running ls -l showed a numeric group id instead of a group name.
I stopped cygserver, net stop "CYGWIN cygserver, and other Cygwin processes, then ran the ls -l again, and group names were then displayed correctly.
I guess cygserver was holding incomplete domain group information.
After restarting cygserver the system continued to work correctly.
#!/bin/bash
find . |while read obj; do
if [[ -d "$obj" ]]; then
setfacl --set "user::rwx,group::r-x,other::r-x" "${obj}"
elif [[ -f "$obj" ]]; then
setfacl --set "user::rw-,group::r--,other::r--" "${obj}"
fi
done
You must specify the group name on the Windows system which your user belongs to.
So I just did this:
chown -R ONEX:Users ~/*
You can find your user name and group here:
Hi I'm using the shell_exec command from a PHP script:
$output = shell_exec('ls -l');
print_r($output);
Terminal: php test.php
Which results in the directory listing as expected.
Switch to my browser I get no output.
I need to grant privileges to the user 'apache' so that it can execute certain commands, or add the user to a group with such privileges. I know how to add users to groups etc, I was just wondering what the best practice method is of granting such privileges to the apache user.
This took me a while to figure out so it may be of benefit to others.
The problem was that I was trying to give the apache user privileges in /etc/sudoers and SELinux was (quite rightly) denying them.
So I quickly disabled SELinux for httpd and all was working.
This is far from an ideal situation though for a public web server.
As for best practices audit2allow should be used to set permissive operations.
If you execute ls -Z in the desired directory, you will see which the SELinux permissions for that directory.
To allow the httpd/apache daemon to access that directory you can execute (the -R option is for make it recursive):
chcon -Rv --type=httpd_sys_content_t /desired/path
Hope it helps.