Files that could be deleted with freeBSD12 cannot be deleted with FreeBS13.

J

jinjin

question about acl permission.
Files that could be deleted with freeBSD12 cannot be deleted with FreeBS13.

I updated os from freebsd12.0 to freensd13.2, and updated samba from Version 4.8.12 to Version 4.19.7.

via samba, user can delete/rename and file in freebsd12.0, but can't delete/rename file in freebsd13.2.

settings about permission are listed below.
Code: 
# getfacl /nas/home/user
# file: /nas/home/user
# owner: root
# group: cifsusers
            group@:rw-p--aARWc---:f-i----:allow
            group@:rwxp--aARWc---:-di----:allow
     user:apiadmin:rwxp--a-R-c---:-------:allow
user:user_name:rwxp--a-R-c---:-------:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:------a-R-c--s:-------:allow
         everyone@:------a-R-c--s:-------:allow

Code: 
# pw show user user
user:*:1120:1001::0:0:User &:/nas/home/user:/usr/sbin/nologin

# pw show group cifsusers
cifsusers:*:1001:

Code: 
# ls -la /nas/home/user
total 5211
drwx------+   7 root            cifsusers        30 Sep 30 00:39 .

if below settings, user can delete/file.
Code: 
# getfacl /nas/home/user
# file: /nas/home/user
# owner: root
# group: cifsusers
            group@:rw----a-R-c--s:-------:allow
            group@:rw-p--aARWc---:f-i----:allow
            group@:rwxp--aARWc---:-di----:allow
     user:apiadmin:rwxp--a-R-c---:-------:allow
user:user:rwxp--a-R-c---:-------:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:------a-R-c--s:-------:allow
         everyone@:------a-R-c--s:-------:allow
or
Code: 
# getfacl /nas/home/user
# file: /nas/home/user
# owner: root
# group: cifsusers
user:user:rwxpDda-R-c---:-------:allow
            group@:rw-p--aARWc---:f-i----:allow
            group@:rwxp--aARWc---:-di----:allow
     user:apiadmin:rwxp--a-R-c---:-------:allow
user:user:rwxp--a-R-c---:-------:allow
            owner@:rwxp--aARWcCos:-------:allow
            group@:------a-R-c--s:-------:allow
         everyone@:------a-R-c--s:-------:allow

or
chmod 770 /nas/home/user
 
/nas/home/user is a directory, not a file. The files within that directory could have a different ACL than the directory. So check the ACL/permissions of the actual file you can't delete.
 
So you have a server. Let's assume it runs FreeBSD, and you have changed versions on it from 12 to 13. It sounds like you are running Samba on that server.

You must also have a client: you say "via Samba ... user can", which sounds like you are coming from a networked client using the CIFS/SMB protocol. We have no idea what the client is (Windows? Mac? Linux or *BSD running a SMB client?). We have no idea what the ID of the user logged into the client is. We have no idea how ID mapping was set up. All we know is that on the server side, seen from the FreeBSD file system side, there is a directory /nas/home/user that has certain permissions and ACLs.

Debugging this would take so much more information than we have. Note that the Samba server is not part of the base FreeBSD OS, but a package or port, so the version of Samba has probably changed also. Given that the basic file/ACL permission checking system in FreeBSD hasn't changed in a long time, it is more likely that the change stems from either Samba, or from a configuration change.

If you want help debugging the problem, please (a) follow SirDice's advice, or (b) give us much more information.
 
SirDice said:
/nas/home/user is a directory, not a file. The files within that directory could have a different ACL than the directory. So check the ACL/permissions of the actual file you can't delete.
Click to expand...
ralphbsz said:
So you have a server. Let's assume it runs FreeBSD, and you have changed versions on it from 12 to 13. It sounds like you are running Samba on that server.

You must also have a client: you say "via Samba ... user can", which sounds like you are coming from a networked client using the CIFS/SMB protocol. We have no idea what the client is (Windows? Mac? Linux or *BSD running a SMB client?). We have no idea what the ID of the user logged into the client is. We have no idea how ID mapping was set up. All we know is that on the server side, seen from the FreeBSD file system side, there is a directory /nas/home/user that has certain permissions and ACLs.

Debugging this would take so much more information than we have. Note that the Samba server is not part of the base FreeBSD OS, but a package or port, so the version of Samba has probably changed also. Given that the basic file/ACL permission checking system in FreeBSD hasn't changed in a long time, it is more likely that the change stems from either Samba, or from a configuration change.

If you want help debugging the problem, please (a) follow SirDice's advice, or (b) give us much more information.
Click to expand...
thanks advice.

When FreeBSD12.0 and Samba4.8.12 , user can delete files within /nas/home/user by settings about permission are listed below. but, When FreeBSD13.2 and Samba4.19.7, user cannot delete files within /nas/home/user .
# getfacl /nas/home/user
# file: /nas/home/user
# owner: root
# group: cifsusers
group@:rw-p--aARWc---:f-i----:allow
group@:rwxp--aARWc---:-di----:allow
user:apiadmin:rwxp--a-R-c---:-------:allow
user:user_name:rwxp--a-R-c---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
Click to expand...
user is access from MAC as a SMB client.

When FreeBSD13.2 and Samba4.19.7, user can delelte files within /nas/home/user . So, I will use below ACL/permissions of the directory. thanks.
# file: /nas/home/user/
# owner: root
# group: cifsusers
group@:----D-a-R-c--s:-------:allow
group@:rw-p--aARWc---:f-i----:allow
group@:rwxp--aARWc---:-di----:allow
user:apiadmin:rwxp--a-R-c---:-------:allow
user:user:rwxp--a-R-c---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
Click to expand...


However, it is strange that user was able to delete files within /nas/home/user by below settings, when using FreeBSD12.0 and Samba4.8.12.
# getfacl /nas/home/user
# file: /nas/home/user
# owner: root
# group: cifsusers
group@:rw-p--aARWc---:f-i----:allow
group@:rwxp--aARWc---:-di----:allow
user:apiadmin:rwxp--a-R-c---:-------:allow
user:user_name:rwxp--a-R-c---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
Click to expand...
 
Strange. I don't have enough ACL experience to decode the output of getfacl in detail. Can you explain (slowly, like talking to a 5-year old) why the ACLs are different on different FreeBSD versions? Did the directories have a different life history?

I somewhat suspect that the problem is less with the FreeBSD file system implementation, and more with Samba. Have you tried asking some Samba experts?
 
ralphbsz said:
Strange. I don't have enough ACL experience to decode the output of getfacl in detail. Can you explain (slowly, like talking to a 5-year old) why the ACLs are different on different FreeBSD versions? Did the directories have a different life history?

I somewhat suspect that the problem is less with the FreeBSD file system implementation, and more with Samba. Have you tried asking some Samba experts?
Click to expand...


When FreeBSD13.2 and Samba4.19.7, below ACL/permissions of the directory.
I add "D" as group@:----D-a-R-c--s:-------:allow . "D" means "delete_child", permission to delete files or directories within a directory.
Code: 
# file: /nas/home/user/
# owner: root
# group: cifsusers
group@:----D-a-R-c--s:-------:allow
group@:rw-p--aARWc---:f-i----:allow
group@:rwxp--aARWc---:-di----:allow
user:apiadmin:rwxp--a-R-c---:-------:allow
user:user:rwxp--a-R-c---:-------:allow
owner@:rwxp--aARWcCos:-------:allow
group@:------a-R-c--s:-------:allow
everyone@:------a-R-c--s:-------:allow
user's group is cifsuser ,so user can delete, probably.

When FreeBSD12.0 and Samba4.8.12 , without the "D", user can delete. Strange.

I haven't asked some Samba experts.
 
You must log in or register to reply here.
Back
Top