We used to get directory content listed with the owner name from HP-UX system using FTP client , recently the system was migrated to Suse-Linux. Now when we FTP to this machine, directory list does not show the owner name of the files.
How would one enable listing directory with owner name in Linux ?
Well in ftp (and most shells anyway), you have the ls command. This prints the list of files.
**Example session** (cutted out some messages):
$ ftp ftp.ed.ac.uk
Connected to luther.is.ed.ac.uk.
220-
Login using the username 'anonymous' and use your email address as password.
ftp> ls
200 PORT command successful
150 Opening ASCII mode data connection for file list
lrwxrwxrwx 1 root root 8 Feb 26 2014 INSTRUCTIONS-FOR-USING-THIS-SERVICE -> .message
drwx-wx-wx 3 root root 4096 Feb 17 14:57 edupload
drwx-wx-wx 3 root root 131072 Feb 17 20:20 incoming
drwxr-xr-x 45 root root 4096 Feb 19 2014 pub
226 Transfer complete
ftp>
The table shows:
drwxdrwxdrwx: d stands for directory, and then rwx for read-write-execute for (in sequential order), the owner, the group and all people with login access;
the name of the owner (root);
the name of the group of the owner (root);
file size;
modification date; and
filename.
Related
I would like to create/ensure a directory exists and recursively copy many files to it using native Puppet methods if possible. The file modes are same for all files but differ from the directory.
I am using Puppet6 version 6.10.0 on CentOS 6.10
This code will create/ensure my directory exists and copy all the files to it but sets the access rights and ownership exactly the same.
file { "/opt/dir1":
ensure => "directory",
owner => "user1",
group => "root",
mode => "0700",
recurse => true,
source => "puppet:///modules/mymodule/dir1",
}
What I get:
ls -la /opt/dir1"
drwx------ 2 user1 root 4096 Sep 23 20:31 .
drwxr-xr-x 7 user1 root 4096 Oct 6 15:20 ..
-rwx------ 1 user1 root 72 Oct 5 17:15 file1
What I want:
ls -la /opt/dir1"
drwx------ 2 user1 root 4096 Sep 23 20:31 .
drwxr-xr-x 7 user1 root 4096 Oct 6 15:20 ..
-rw-r--r-- 1 user1 root 72 Oct 5 17:15 file1
If you are able to manage the permissions and mode in the source you can use this parameter source_permissions => use. Note, depending on your version you may get a deprecated warning:
Warning: The `source_permissions` parameter is deprecated. Explicitly set `owner`, `group`, and `mode`.
file { "/opt/dir1":
ensure => "directory",
owner => "user1",
group => "root",
source_permissions => "use",
recurse => true,
source => "puppet:///modules/mymodule/dir1",
}
This would allow you do manage the mode in the source but still override the owner and group. you could also drop the owner and group params above and manage them in the source as well. However I'm not sure how this works if you have windows clients and a linux puppet master, or a missmatch in users/groups on the master vs agent
The Puppet file resource can't set different modes for the apex directory and its files when using recurse. https://puppet.com/docs/puppet/5.5/types/file.html#file-attribute-mode
Would you be able to use an archive resource instead? With an archive resource, you can specify a tar file as the source, and the permissions will be set following those in the tar file.
In my open vpn server, i am ensuring cron file permission to be only accessable from root user.
I have removed the at.deny and cron.deny files and have created at.allow and cron.allow and 0600 permissions are applied for files, both files are empty and file permissions are as below, which clearly says root has read and write access.
-rw------- 1 root root 0 Jul 21 08:40 cron.allow
-rw------- 1 root root 0 Jul 21 08:40 at.allow
however this change allows my openvpnas user to still list the crontab and even allows to edit cron.
openvpnas#openvpnas2:~$ crontab -l
no crontab for openvpnas
Where as when the file permissions are as below,
-rw-r--r-- 1 root root 0 Jul 21 08:41 cron.allow
-rw-r--r-- 1 root root 0 Jul 21 08:41 at.allow
It restricts my non root users to access or edit cron files! This issue is only with one of my server, where as other server permissions and behaviours are as expected,
openvpnas#openvpnas2:~$ crontab -l
You (openvpnas) are not allowed to use this program (crontab)
See crontab(1) for more information
Please provide your inputs on this, this has kept me blocked from continuing my work.
This issue i faced was in Ubuntu 18.04 instance,
Current /usr/bin/crontab permission was as below,
-rwxr-sr-x 1 root crontab 39352 Nov 16 2017 /usr/bin/crontab
Had to change the group user from crontab to root and file permission to as below,
sudo chmod 4755 /usr/bin/crontab
sudo chown root:root /usr/bin/crontab
-rwsr-xr-x 1 root root 39352 Nov 16 2017 /usr/bin/crontab
This permission restricts the non-root user to schedule cronjobs. The access can be allowed to non-root users by adding the user names in cron.allow file.
openvpnas#openvpnas2:~$ crontab -l
You (openvpnas) are not allowed to use this program (crontab)
See crontab(1) for more information
I have centos in VMware and hosted a web application.
This is the url I try to access my page. There is also another demo page "demo.php" that I create for test. its fine can access and prints contents: "its ok." but when I try to my app page which in same directory the browser says:
Forbidden
You don't have permission to access /WP/View/Home/localobjects.php on this server.
http://192.168.118.129/WP/View/Home/localobjects.php
How can I fix this?
Files Permissions in directory.
-rw-r--rwx. 1 root root 272 Apr 2 00:49 activedirectoryusers.php
-rw-r--rwx. 1 root root 236 Apr 17 01:22 configuration.php
-rw-r--rwx. 1 root root 324 Mar 30 00:59 dashboard.php
-rw-r--r--. 1 root root 107 Apr 15 08:28 deneme.php
drwxr-xrwx. 2 root root 4096 Apr 17 01:22 Ipageimplementations
-rw-r--rwx. 1 root root 257 Apr 17 00:52 localobjects.php
-rw-r--rwx. 1 root root 224 Mar 28 18:41 policy.php
-rw-r--rwx. 1 root root 257 Apr 13 01:58 timeintervals.php
Here is a cheatsheet…
Directories must have the permissions "drwxr-xr-x".
You set them with chmod 755 [directory name].
Files must have the permissions "-rw-r--r--".
You set them with chmod 644 *php for all the php files in a folder. If you have other files which must be seen on the web (.css, etc.) chmod them accordingly.
To get the "magic numbers" you have three digits:
the first one is for the owner
the second one is for the owner's group
the third is for the rest of the world
Numbers are the sum of:
4: readable
2: writeable
1: executable
In doubt, make a directory at a time: if you give wrong permissions (not executable, like files) to a folder you can't browse it.
Story: I deleted a directory LogViewer from the document root that was browseable and working perfectly. Later I decided to add it back but now apache wont show it.
drwxr-xr-x. 12 user group 4096 Jun 19 15:16 272
drwxr-xr-x. 12 user group 4096 Jun 19 15:17 273
drwxr-xr-x. 3 user group 4096 Jun 20 08:06 LogViewer
The 272 and 273 directories are browsable and work.
Output of ls -lZ:
drwxr-xr-x. user group system_u:object_r:httpd_sys_content_t:s0 272
drwxr-xr-x. user group system_u:object_r:httpd_sys_content_t:s0 273
drwxr-xr-x. user group unconfined_u:object_r:user_home_t:s0 LogViewer
What I've Tried:
I have restarted apache multiple times. I've stopped it, and started it. I've refreshed the browser, I've cleared cookies and all temp files.
My Question: Wtf?
As per: SELinux doc
To make a folder viewable from a special user public HTML folder, it
needs to have a type that httpd has permissions to read, presuming the
Apache HTTP Server is configured for UserDir and the Boolean value
httpd_enable_homedirs is enabled.
Try this command:
chcon -R -t httpd_user_content_t LogViewer
My crontab isn't running and I'm trying to figure out why. I've created a symbolic link within /etc/cron.d to /var/www/mysite.crontab
user#ip-xxxxxxxxxx:/etc/cron.d$ ll
total 20
drwxr-xr-x 2 root root 4096 Apr 11 03:48 ./
drwxr-xr-x 96 root root 4096 Apr 16 00:50 ../
lrwxrwxrwx 1 root root 30 Apr 11 03:47 mysite.crontab -> /var/www/mysite.crontab
-rw-r--r-- 1 root root 124 Feb 27 2012 drupal7
-rw-r--r-- 1 root root 544 Sep 12 2012 php5
-rw-r--r-- 1 root root 102 Apr 2 2012 .placeholder
The actual cron file is...
#Purge old deals
4 1 * * * www-data wget -q -O- http://www.mysite.com/cron/clean > /dev/null 2>&1;
Oddly enough the problem is with the name of the file. You are not permitted to use a . as a part of the name of the file when present in the /etc/cron.d dirctory.
The logic for this is in the database.c file, in the function valid_name. Renaming the file to something like mysite_crontab should fix the issue.
In general, the filename should probably just be a simple name mysite the fact that it's in this directory implies that it's a cron file already.
The file that is being pointed to must be owned by root, this is stated in the man page for the support of the /etc/cron.d directory:
Support for /etc/cron.d is included in the cron daemon itself, which handles this location as the system-wide crontab spool. This directory can contain any file defining tasks following the format used in /etc/crontab, i.e. unlike the user cron spool, these files must provide the username to run the task as in the task definition.
Files in this directory have to be owned by root, do not need to be executable (they are configuration files, just like /etc/crontab) and must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens. This means that they cannot contain any dots. If the -l option is specified to cron (this option can be setup through /etc/default/cron, see below), then they must conform to the LSB namespace specification, exactly as in the --lsbsysinit option in run-parts.
The intended purpose of this feature is to allow packages that require finer control of their scheduling than the /etc/cron.{hourly,daily,weekly,monthly} directories to add a crontab file to /etc/cron.d. Such files should be named after the package that supplies them.