On Tue, Dec 08, 2020 at 06:08:12PM +0100, MichaIng wrote:
> Good idea, although it would have been recognised much earlier
> during nearly every normal system operation:
> -------
> root@micha:/tmp# set -o | grep noclobber
> noclobber off
> -------
>
> strace is a fantastic idea, but it seems to fail on the lowest level
> "EACCES (Permission denied)":
> -------
[...]
> openat(AT_FDCWD, "testdir/testfile",
> O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = -1 EACCES (Permission
> denied)
[...]
Thanks for your patience :)
Aha, but we now know the syscall, open(at). And it's being called
with O_CREAT.
This is what man openat(2) has to say on that:
O_CREAT
If pathname does not exist, create it as a regular file.
The owner (user ID) of the new file is set to the effective
user ID of the process.
The group ownership (group ID) of the new file is set either
to the effective group ID of the process (System V semantics)
or to the group ID of the parent directory (BSD semantics).
On Linux, the behavior depends on whether the set-group-ID
mode bit is set on the parent directory: if that bit is set,
then BSD semantics apply; otherwise, System V semantics apply.
For some filesystems, the behavior also depends on the bsdgroups
and sysvgroups mount options described in mount(8)).
The mode argument specifies the file mode bits be applied when
a new file is created. This argument must be supplied when
O_CREAT or O_TMPFILE is specified in flags; if neither O_CREAT
nor O_TMPFILE is specified, then mode is ignored. The effective
mode is modified by the process's umask in the usual way: in the
absence of a default ACL, the mode of the created file is
(mode & ~umask). Note that this mode applies only to future
accesses of the newly created file; the open() call that creates
a read-only file may well return a read/write file descriptor.
I lost track a bit about your other hypotheses, but this mode changing
bit when O_CREAT is given somehow rings a bell.
Cheers
- t
Attachment:
signature.asc
Description: Digital signature