Timeline for When (and how) are file permission/access decisions made in kernel space?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2024 at 22:02 | vote | accept | genericuser99 | ||
| Mar 26, 2024 at 20:39 | history | became hot network question | |||
| Mar 26, 2024 at 18:52 | comment | added | ilkkachu |
I think it runs the given command regardless of -F, that's what it seems to me anyway. And it says it records "events that happen while the command executes", or until you hit Ctrl-C so it has to run it know the "during". Also, "Using -F will let you trace only events that are caused by the given command.", which seems to imply that otherwise it traces, umm, everything? So, in a way, it looks like trace-cmd record -F somecmd... works similarly to strace somecmd.... I can't really read heads or tails from the output though, so it's hard to be sure.
|
|
| Mar 26, 2024 at 18:23 | answer | added | genericuser99 | timeline score: 3 | |
| Mar 26, 2024 at 17:55 | comment | added | genericuser99 | @ilkkachu Worse still, "-F" was indeed just causing the /bin/ls command to run itself, as opposed to waiting until it saw it running - so I was seeing the output from just running it as root (given trace-cmd was running as root). Now that is really embarrassing, especially since I missed your comment saying exactly this! | |
| Mar 26, 2024 at 17:48 | comment | added | genericuser99 | @ilkkachu Embarrassingly, user error is the culprit. Both my original understanding, and your understanding with regards to permission checks being done at the time of the open call were correct. The issue, I think, seems to be my lack of understanding of trace-cmd, and specifically the "-F" flag. I assumed I tell it to watch that binary in one terminal, and then run the binary in the other, and it'll trace that. But the minute I run the command, it had already populated the trace - populated with what, I don't know, but it wasn't actually the data from me running the "ls" myself! | |
| Mar 26, 2024 at 15:45 | comment | added | ilkkachu |
Everything I know says that permissions checks are mostly done just at the time of open(), not at the time of read() (or getdents()), and it would seem odd for one tracer to show a different result than another. Accidentally running it against a wrong directory would be a rather simple explanation (if almost a bit too convenient), and not at all as uncommon a mistake to make than what one might hope!
|
|
| Mar 26, 2024 at 15:44 | comment | added | ilkkachu |
ok, I'll admit I don't know anything about trace-cmd. But, if I run trace-cmd record -p function_graph -F /bin/ls, it prints me the listing of the current directory, and the same with -l / at the end prints a long listing of the root directory, so it seems to me, it'd just run the program with the given options then and there.
|
|
| Mar 26, 2024 at 13:41 | history | edited | genericuser99 | CC BY-SA 4.0 |
Added further clarification around the execution of trace-cmd
|
| Mar 26, 2024 at 13:25 | comment | added | genericuser99 |
As I understand it, the -F flag on the trace-cmd is the binary to trace. In a separate terminal tab, I run the ls command, which is captured by trace-cmd. I'll add that into the original question for clarity. In terms of trace-cmd output, all you get (from how I was running it) is a function call chain - so you can essentially see a formatted code block sequence like: foo() -> bar() -> baz() But not args passed to functions, or what's returned. So, I can't be sure what the gendents syscall is actually being run on, only that it is being run (but not in the strace output)
|
|
| Mar 26, 2024 at 12:51 | history | edited | genericuser99 | CC BY-SA 4.0 |
added 135 characters in body
|
| S Mar 26, 2024 at 12:39 | review | First questions | |||
| Mar 26, 2024 at 18:55 | |||||
| S Mar 26, 2024 at 12:39 | history | asked | genericuser99 | CC BY-SA 4.0 |