Thread: File opening

Code:

CreateFile("C:\\quux\\bar.foo", GENERIC_READ | GENERIC_WRITE, 
        FILE_SHARE_READ, NULL, OPEN_ALWAYS, 
        FILE_ATTRIBUTE_NORMAL, NULL);

Creates ( or opens an existing ) file to read and write, and lets other applications read the file, but not write to it. Now...
Is there a way to do this in Linux??

You could try the locking sections of -> fcntl(2): change file descriptor - Linux man page

Changing the file descriptor won't prevent other processes from accessing the file if they have the correct permissions. Which you should look at man chmod if you aren't aware of how linux file permissions work.

So one way to do this would be to create a new user specifically for your application, and set the files it creates 644 (the default), which allows the owner to read and write, and others just to read. For a normal (non root) user, that is your perspective on most of the system.

Linux also has "advisory" file locks you can apply (they are mentioned in the man page Salem linked above). The idea is that other processes should first check to make sure a file is not locked before accessing it. However, the locks are not enforcable -- if you don't check or don't care, the lock can be ignored.

SELinux, which is standard on fedora and optional elsewhere, has more specific ways of enforcing rules than basic permissions, but it is slightly arcane.

Originally Posted by MK27

Changing the file descriptor won't prevent other processes from accessing the file if they have the correct permissions. Which you should look at man chmod if you aren't aware of how linux file permissions work.

So one way to do this would be to create a new user specifically for your application, and set the files it creates 644 (the default), which allows the owner to read and write, and others just to read. For a normal (non root) user, that is your perspective on most of the system.

Linux also has "advisory" file locks you can apply (they are mentioned in the man page Salem linked above). The idea is that other processes should first check to make sure a file is not locked before accessing it. However, the locks are not enforcable -- if you don't check or don't care, the lock can be ignored.

SELinux, which is standard on fedora and optional elsewhere, has more specific ways of enforcing rules than basic permissions, but it is slightly arcane.

Is there a somewhat simple way to create a new user from within a program running with root privileges?

Originally Posted by Benji Wiebe

Is there a somewhat simple way to create a new user from within a program running with root privileges?

I suppose, but it doesn't seem like a good idea to me. The concept with users and privileges is that they are relatively permanent. Creating a new user temporarily will not get you around any of the limitations mentioned in the rest of this post.

Let's say you have an application that you want to run that creates and edits files that other users are only allowed to see, not change. So you create a new user manually, and then the program would change its user id when it runs, qv.

Setting User ID - The GNU C Library

Nb, you generally cannot do this if you start the program as a normal user, it would have to be started root. After that, it is somewhat defanged (because it is not root), but it is running as a unique user, meaning it can create files with permissions set as previously described. A lot of linux daemons work this way. You can create users who do not have login privileges, so no one can log in as them -- their account can only be accessed by root using "su", or a root process using setuid().

I am sure it is not possible to have a program that you start as a normal user that can then do something such that it could create files that you could not also read and write outside of the program, if that is want you want. Also, you cannot lock root out of anything.

Maybe you should describe more specifically what it is you want to do and why, and someone can provide some better suggestions.

I kind of like the "temp user" idea, even though it's a bit unconventional. Not only is it sandboxed against the rest of the system, it has an unguessable UID and username, has no password, and exists only momentarily. Most systems have a "nobody" account which is supposed to be the least privileged on the system, the problem is there's only one of them so if more than one daemon or application wants something like that they need to beg root to make an account for it. If you could make some unprivileged call (any process can do it) which creates (and switches to) an anonymous user guaranteed to be different from any other user on the system, I can think of a lot of good uses for that.

Originally Posted by brewbuck

I kind of like the "temp user" idea, even though it's a bit unconventional. Not only is it sandboxed against the rest of the system, it has an unguessable UID and username,

No,

1) the UID and username would be in /etc/passwd (even if there is no passwd), at least until you delete the user. Then...
2) since the OP states that the file is okay for others to read, all they have to do is run stat to get the "unguessable" UID of the file or process. Process and file UID's are not hidden from anyone, regardless of how unique or temporary they are.

If the file were supposed to be hidden, using a unique user would be worse than pointless, because all of a sudden your needle in a haystack has a big "Where's Waldo?" hat on it. It would be good to chown the file to something other than the process id, but not an unusual one, because when someone catches up with that game, they will know exactly what to look for (files with unusual uid's).

If you could make some unprivileged call (any process can do it) which creates (and switches to) an anonymous user guaranteed to be different from any other user on the system, I can think of a lot of good uses for that.

Maybe, but in this context I don't see how it would be useful.

I don't know what you're doing but if you were to try to create new users on any Linux system I used, I'd throw your program in the bin. That's the sort of thing you leave to a sysadmin during an installation process and not just have your program doing. Stopping other applications accessing the file is a bit outside the scope of the chmod attributes on Linux. It doesn't work on applications, only users, and users can run as many applications as they like and the applications can all do what they like (unless you're using SELinux or ACL's) as that user.

Why would you want to prevent other applications from accessing that file? The only "clean" solution is to add a user for that particular program and run exclusively as that user, then you can do what you like so long as there are no other applications running as that user (which there can easily be, but nobody would bother). Why specifically must other applications be unable to write to that file, outside of normal file locking semantics?

Originally Posted by ledow

I don't know what you're doing but if you were to try to create new users on any Linux system I used, I'd throw your program in the bin.

/usr/bin or bin bin?

I agree with ledow. I think the best bet here is the traditional one: create a new permanent user only for that program, start the program as root, then setuid to the special user (or, su to the special user, then start the program; you may want to look at the nohup command if you do that).

Originally Posted by ledow

...Why would you want to prevent other applications from accessing that file?...

How about a "good" white-list web filter that has a list of domains that no-one can go and edit any time they feel like it?

Originally Posted by Benji Wiebe

How about a "good" white-list web filter that has a list of domains that no-one can go and edit any time they feel like it?

This is why you have a system of users and permissions. An application may be bound by the contents of a file it can read (such as a white-list) but cannot modify/write. That way, it can be run by a user with insufficient privileges to create or change the white-list.