Human users have UIDs starting at 1000, so you can use that fact to filter out the non-humans:
cut -d: -f1,3 /etc/passwd | egrep ':[0-9]{4}$' | cut -d: -f1
This cuts the first (username) and third (UID) colon-delimited fields from /etc/passwd, then filters for the resulting lines which end with a colon and four digits, then cuts the first (username) field from that, leaving you with a list of users with UIDs between 1000 and 9999.
If you have more than nine thousand users on your system, this will fail - but it's necessary to restrict the result to 4-digit UIDs in order not to catch nobody (UID 65534).
Try this procedure.
Create shared folder and give right permission:
mkdir /pathYouWant/share
chmod 770 /pathYouWant/share
This gives no access to other.
chmod +t /pathYouWant/share
This mode, according to chmod manual page:
The restricted deletion flag or sticky bit is a single bit, whose
interpretation depends on the file type. For directories, it prevents
unprivileged users from removing or renaming a file in the directory
unless they own the file or the directory
As told by Marty Fried files created in the share folder should have the right permissions and this can be achieved with samba share masks in smb.conf:
create mask = 440
directory mask = 550
Windows programs shouldn't try to remove read-only files unless delete readonly option is set to yes.
delete readonly = no
Also if you want to hide all file in share folder:
veto files = /*/
delete veto files = no
According to samba manual these directive:
What happens if the user tries to delete a directory that contains
vetoed files? This is where the delete veto files option comes in. If
this Boolean option is set to yes, the user can delete both the
regular files and the vetoed files in the directory, and the directory
itself is removed. If the option is set to no, the user cannot delete
the vetoed files, and consequently the directory is not deleted
either. From the user's perspective, the directory appears empty, but
cannot be removed.
After this configuration, the only problem left is that user can still delete his/her own files even if he/she do not see it (It is unclear to us why).
So we decide to follow the_Seppi suggestion to complete the task and Bram Driesen did a script that changes file ownership to the host pc.
He used incron to fire the script whenever a file is placed in the folder, following this as guide to set it up.
Best Answer
The existence of a user account in itself does not mean that user has any privileges, whether it's a "system" user or a regular user. If you went ahead and created a new system account it would be able to do nothing - it would have the same privileges as
nobody(indeed, most system accounts are created for the purpose of giving something as few privileges as possible). Only someone with the privileges to do so (ie, superuser) can give another user privileges, by modifying ownership or permissions in the filesystem.The onwership and permissions throughout a complete Linux installation are so complex that you can't describe exactly what they all should be in a single post. If you suspect that your system has been compromised, you'd have to tailor your treatment based on exactly what the situation is. If you have no reason to suspect this is the case then it would be impractical to audit everything in your system to ensure nothing has more permissions than it should.
Another note: system accounts generally don't have a password because you don't ever need to log in to them. When an account lacks a password in
.passwd, it doesn't mean you can log in with no password, it means you can't log in to that account at all. The account can only be used when a privileged process spawns or switches itself to using that account.