Exclude swap files (.swp) from containment statements

[csarven]

https://fileinfo.com/extension/swp

.swp file is created when a text editor like nano or vim opens a file in a directory. When the editor is closed, the swap file is removed.

While swap files exist in a directory, NSS includes them in containment statements.

My attempts to GET the .swp file resulted in a 404, but this could still be a potential risk. At the very least, it does expose information when it really shouldn't.

I suggest excluding .swp from containment statements.

[bourgeoa]

@csarven I propose to exclude all dot (/.xxx) filenames with the exception of /.meta and /.acl In Containement statements /.meta are included as text/turtle and .acl's are excluded.

[csarven]

This is not a requirement in the Solid Protocol but it could perhaps be an advisement where an implementation could implement the following:

Servers are advised to respond with the 403 status code to HTTP PUT, PATCH, POST requests where the request target's last path segment begins with the character ".".

solid-protocol-consideration

[bourgeoa]

This is not a requirement in the Solid Protocol but it could perhaps be an advisement where an implementation could implement the following:

Servers are advised to respond with the 403 status code to HTTP PUT, PATCH, POST requests where the request target's last path segment begins with the character ".".

solid-protocol-consideration

Not sure it is a good idea. There may be situation where dot files could be used. for example some apps have used container/.dummy to create containers This has been used by solidOS in the past and is still in the test-suite.

It may also be a way to add non RDF metadata to resources.

In any case dot files not displayed in containment statements shall be included when deleting a container

[csarven]

If applications can create dot files (for any purpose) and they're hidden from containment, then there is no way for applications to manage them consistently. And this becomes problematic when different applications want to perform read or write operations on the dot files. This gets complicated quick, see for example: https://github.com/solid/specification/issues/116 , https://github.com/solid/specification/issues/626 .

If Solid Protocol specifies or encourages dot files to not be listed in containment statements, there needs to be additional behaviour indicating what to do with them. Otherwise, dot file management is an implementation detail.

I understand that dot files can be useful, so creating should be possible. However, imposing additional certain semantics on such URIs (last path segment beginning with the character ".") needs to be detailed further.

It is within server's rights to protect or reserve read-write on any URI. I would suggest that each server should have an index of path segments that it prevents read and write operations. .swp could be one example among many.

See also https://github.com/solid/specification/issues/626#issuecomment-1962899851 for some thoughts..

[zg009]

@csarven Would configuring Solid-compliant resource servers with at least one access control suffix, one metadata suffix, and 0 or more extra suffixes suffice? In my first opinion, they would get treated similarly as .meta.

I read your proposal but I am not sure I agree with the advertisement of these resources in headers/discovery. It may be a potential probe vector, or attacker may be able to figure out more information based on restricted suffix exposure.

[csarven]

403 is the typical response to an unauthorized request.

What additional knowledge can an attacker gain by looking at the source code and obtaining the knowledge that requests to certain URI paths are automaticlaly forbidden?

As for the discovery of ACL resources and Description Resources, the naming is not relevant because there is a discovery mechanism that happens through a link relation - which is part of the Solid Protocol specification.

More generally, the server should not expose information more than necessary. That goes for any resource that can potentially be discovered from a container. In the example here, clearly a particular file - ending .swp - is an artifact that is unique to the storage (file)system. It is exposed due to reasons beyond the Solid Protocol. The server should take care to control the visibility irrespective to access controls. It is not only a security concern by generally an unintended side-effect of the storage system in use. Here is the relevant advisement from the Solid Protocol ( last sentence in paragraph https://solidproject.org/ED/protocol#consider-request-validation ):

Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.

What feature is .swp or any arbitrary unintended resource appearing in containment listing?

[zg009]

I think I misunderstood your proposal then, my mistake.

What additional knowledge can an attacker gain by looking at the source code and obtaining the knowledge that requests to certain URI paths are automaticlaly forbidden?

I was not referring to the source code of NSS - I was referring to point 2 of your recommendation which is "Specific data model for their discovery and description." which on reading I thought was respect to how to manage dot-file resources, but may have just been a reference to how .gitignore works. I was thinking by discovery you meant exposing the restricted suffixes in a response header or on an OPTIONS request, or something of the sort when 'discovery' was mentioned.

What feature is .swp or any arbitrary unintended resource appearing in containment listing?

I do not understand this question. I am in agreement with you that just a regular 4xx response on trying to access protected files is the correct way to go. I was asking more internally if having a configuration option for NSS or other possible server implementations which treats all specified restricted file extensions as untouchable by user interactions.