Each process has “owner” and “group”. By default, files created by process get that owner and group.
The group sticky bit (g+s) on directory changes that:
The group directory is used as group of file
If the new file is a directory, then it gets the group sticky bit
I don’t recall seeing owner being inherited – it definitely is not feature of the group sticky bit.
The owner ‘root’ on /var/www/html/te/testfile.txt tells that you did run touch /var/www/html/te/testfile.txt as user root. If you were already root,
then why did you run other commands with sudo? (That would be redundant.)
The owner/user is correct. It will always be root, or “username”. The group sticky bit (g+s) means that the group assigned to the directory, and all members of that group can edit/amend the file. The username part is irrelevant and can be ignored. You would need to be the apache user, for that value/permission to change. For all other users a part of the group apache, will then ensure that it is always apache, irrespective of whoever edits it. Assuming that the group sticky bit was set.
thanks for the explanation sir, I originally thought that it was also necessary to change the owner to ‘apache’, to make it works correctly with apache server - read/write
The Apache server process has owner ‘apache’ and group ‘apache’.
The directory has group ‘apache’ and that group can read and write,
so the Apache server process can read and write to that directory.
That is, by the POSIX permissions. The Apache server process is also
confined within “httpd” SELinux context, but if you do look at:
ls -lRZ /var/www/html
you should see that all files and directories within do have httpd_sys_content_t