Where to include "access" unix function in Rust API

[jespino]

Hi, I need a function that check the permissions of the current user in a file (this is the unix access function). In rust i can use the unsafe function libc::access, but I think must more sense to have it on the File Metadata object or MetadataExt.

I’m thinking about make a pull request to rust with this function (calling libc::access) but I want to know if this approach is correct, and where to include it.

Regards.

[burntsushi]

Could you explain a bit more about the problem you’re trying to solve? Specifically, why doesn’t std::fs::Permissions address your problem?

Permissions are hard to get right in a cross platform way, so if you need/want Unix style permissions, you can import a platform specific trait: https://doc.rust-lang.org/std/os/unix/fs/trait.PermissionsExt.html

[jespino]

Yes, of course, the problem I want to solve is related to the access rights to a file for the current user, Permissions only allow to check if the file is read only, and the PermissionsExt only allow to get the permissions of the file “globally” not related to the current user. The access function give me the response to the question “Have I permission to (read, write, execute) this file?”.

I’m happy with a Unix only implementation, in the PermissionsExt trait, for example. My objective is to use this in Unix.

[burntsushi]

@jespino This is a quote from the man page for access

Warning: Using these calls to check if a user is authorized to, for example, open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. For this reason, the use of this system call should be avoided.

Instead, you might consider just trying to open the file. If the user doesn’t have permission to read it, the open call will fail.

If that still doesn’t fit your use case, then I might recommend creating a new crate that defines a safe wrapper around access using the libc crate.

[cuviper]

That security warning comes about because access checks the real UID and GID, not the effective IDs. Real and effective are usually the same, but not when running a setuid program for instance. So if such a program tries access() to confirm real permissions, then proceeds to open() with the effective permissions, this is a classic TOCTOU race. In this scenario, the advice to "just use open" requires you to drop down to the real IDs first.

There’s also more to access() than just checking mode bits, for instance when there are ACLs on a file.

[jespino]

Hi,

I’m agree, probably the access aproach isn’t the best one for this. The problem is Open allow to check read and write permissions, but don’t allow to check excecution permissions. Is there any function to do this?

Anyway, the API for check permissions about my current users is really limited, and non-intuitive, for example, I have a permissions trait, to check the permissions of the file, I can check if the file is read_only, but i can’t check if the file is readable, or writeable, or executable. And the workaround of use Open and OpenOptions works, but IMHO it isn’t intuitive.

I think the Permissions trait, or the PermissionsExt trait, can be more useful with this kind of checks.

I can write a crate with a trait with this, but I think is something that I expect to find in the standard library.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.