Root does not respect default ACL?

General Chat
1

I set the default file permissions using the following commands

chmod -R u=rwX,g=rX,o=rX dir
setfacl -Rm user:foo:rwX dir
setfacl -Rdm user:foo:rwX dir

and if I create e.g. a textfile inside dir the file permissions are as expected

user::rw-
user:foo:rwx		#effective:rw-
group::r-x		#effective:r--
mask::rw-
other::r--

However, if I open a root session, create a root file and save it in dir the permissions are unexpectedly the following

user::rw-
user:foo:rwx		#effective:r--
group::r-x		#effective:r--
mask::r--
other::r--

Why does root not respect the default ACL of the directory and is there a way to change that behavior?

1 Like
2

I guess @pcanal or @Axel or @amadio l will know.

3

Hi Katharina,

No idea! ROOT just opens the file with read and write permissions. I don’t understand why AFS would set the mask field differently than the default.

I tried to reproduce this but I get:

$ setfacl -Rm user:foo:rwX TMP
setfacl: Option -m: Invalid argument near character 6

What am I doing wrong?

Cheers, Axel.

4

@Axel foo stands for a specific username so try substituting it with yours. It is meant to grant access to specific users only. Anyways, also without all the extra ACL stuff it appears that root writes files without write permission for the group. Any clue how I can change that?

Let me be more specific… Usually the default file permissions are defined by umask but also with umask 002 root does not give write permissions to the group for newly created files. Try the following

umask 002
touch foo

now open a root session and create a file

TFile f("bar.root","recreate")
f.Close()

and check the permissions. I find them to be

-rw-rw-r--. foo
-rw-r--r--. bar.root

and I don’t know why they should be different…

5

Great, that helped a lot, thanks! @pcanal - any hints?

We have, in TFile.cxx:509:

      fD = TFile::SysOpen(fname, O_RDWR | O_CREAT, 0644);

That would explain it I suppose?

Axel.

6

Great! That explains a lot! This seems very hard coded to me so probably there is no way around but to change the permissions afterwards…
Thanks a lot!

7

Sorry for not being explicit about that: while the code might explain the behavior, it totally doesn’t explain why it behaves that way :slight_smile: @pcanal is our best bet for that. I’d argue it’s a bug that we should get fixed - thanks for pointing this out, Katharina!

Just for the record, this exists since the beginning of time of recent version controls:

commit 852600061bcacd9b255d44f6312c96b6b1e00a2d
Author: Fons Rademakers <Fons.Rademakers@cern.ch>
Date:   Tue May 16 17:00:58 2000 +0000

    This commit was generated by cvs2svn to compensate for changes in r2,
    which included commits to RCS files with non-trunk default branches.

    git-svn-id: http://root.cern.ch/svn/root/trunk@3 27541ba8-7e3a-0410-8455-c3a389f83636

introduces it: commit number 3!

Axel.

8

This is an ancient decision (Maybe @rdm remembers why this was choosen) that ends up requesting a more restrictive persmission set that then one you allowed.

At the moment I do not know whether this was a decision made to implement user request or to deal with challenge in the implementation of file permission at the time.

9

We decided on hardcoded 0644 in the very beginning to be safe and only create files that could be changed by the owner (ACL’s did not exist at the time). Having this hardcoded prevented also frameworks from changing it to some surprising setting somewhere deep down. Till now this decision worked fine as ROOT left the file management to external file management tools that typically manage the permissions and ACL’s depending on specific policies.

Fons.

1 Like