-2

So in Linux we have a concept of file permission. There are three classes: user, group, and others, and there are three types of permissions: read, write, and execute.

Now consider this. You are on a remote computer, you open a web browser, you access a static site on a (Linux) server, and the browser downloads the static files such as html files and image files from the server.

In this case, you did not login to the server with a user account. So how were you able to access the html files and image files? What "user" was used? Is it the "others" user? But how?

Or does file permission only works when files are accessed via shell?

7
  • 3
    What user was the web server running as? Commented Feb 5, 2023 at 22:20
  • The browser does not download any files. It negotiates with the web server via TCP/IP protocols, and makes requests that result in messages being returned. Most web "pages" are never files -- they are dynamically created on request using database queries, which is another level of API with its own server-side permissions regime. Commented Feb 6, 2023 at 0:29
  • @Paul_Pedant but the question's context is non-dynamic websites: "... you access a static site on a (Linux) server, and the browser downloads the static files ...". Commented Feb 6, 2023 at 5:08
  • @SottoVoce You can access static local files from a browser directly, with a URL like file:///home/paul/SandBox/, in which case the file permissions are enforced in respect of the user who owns the browser process. If the browser is talking to a web server (whether local or remote, and whether the pages are dynamic or static) the browser has no idea of their origin. The OP specifically asks about a remote server, and asserts the files are "downloaded". That is a fallacy. The OP's Title also asks about shell, implying that permissions do not apply when processes open files themselves. Commented Feb 6, 2023 at 9:02
  • 1
    @Noob_Guy the permissions you ask about are filesystem entities, not shell entities. The permissions affect access to filesystem objects (e.g., files) whether the access is being made by a shell or by other executable code (such as web server daemon, a database daemon, and so on). Commented Feb 7, 2023 at 3:46

1 Answer 1

-1

The web server runs in the background under a system-level user account. You're using that user's permissions in this scenario.

System users are created via mechanisms like useradd --system and generally cannot be logged into. Even so, they're legitimate "users" for the purposes of permission checking.

If you look in /etc/group, you're likely to find a group named after the particular web server you're using (nginx, apache, etc.) or something generic (e.g. wwwdata) so that you can chgrp your static files to be readable by the web server without changing their ownership.

3
  • We don't know what user id the remote web server runs under. All we do know, is that the local browser asks for some resource over the network, and the server gives it whatever it sees useful to give. Any access control on the remote is the business of that remote, and if it's a run of the mill Unixy system, the file access control is based on the user id used by the process opening the file on the server. (It might be some "system-level" account, but that doesn't matter in the least, it's all just user ids as far as the access controls are concerned.) Commented Feb 24, 2023 at 7:55
  • I'm playing the odds on packaging defaults here, while you're taking an 0.01% position to be "right." Commented Feb 24, 2023 at 8:34
  • And at the same time, you're muddying how it works by bringing in "system-level user accounts" as a red herring. They don't matter, as far as the UID-based permission checks are, a system-level/non-system-level distinction doesn't exist. It works the same even if the server runs under a "non-system user". Commented Feb 24, 2023 at 9:29

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.