LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 04-27-2013, 04:48 PM   #1
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Rep: Reputation: 0
Execute with group permission but write with other permission?


I want to allow users of a group to execute a script which then writes out to a file. I want users to run this script to write to the file but not be allowed to write to the file directly.

How might I accomplish this?
 
Old 04-27-2013, 07:59 PM   #2
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,258

Rep: Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328
I think you'd have to use suid if this was a binary, causing the program to run as the program user, not as the user.
However, suid is not honoured by the kernel for scripts, due to security issues.
Running a script is the same as running the cmds yourself, so I'm not sure you can accomplish what you want.
Perhaps if you told us why you think you need this ie what are you trying to achieve.

You could try using inotifywait to change the file ownerships upon creation http://linux.die.net/man/1/inotifywait.
See here http://www.linuxquestions.org/questi...364/page2.html
 
Old 04-27-2013, 08:08 PM   #3
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 816

Rep: Reputation: 254Reputation: 254Reputation: 254
You may be able to use the "setuid" bit on the script to run it as a different user. In other words, a non-privileged user runs the script, but the script file has the "setuid" bit set on its permissions. The owner of the script has permission to write the file. Alternatively you can use "setgid" to run the script as a member of a different group.

Some Linux distos do not allow "setuid" (and possibly not "setgid") for scripts.

Here's a link to a good explanation about that.

Tuxation - setuid on shell scripts


As an example, suppose you give "mygroup" execute permission for a script or program. That means the program's group id must be "mygroup". If the owner of the program is "mygroupadmin" then you also set the "setuid" bit so the program runs as "mygroupadmin" no matter who runs the program. The program creates a file, and sets the file permissions to deny "mygroup" write premission. The file has "mygroupadmin" as the owner with write permission.

You have to be careful about other permissions too. If "mygroup" has write access to the directory, then anyone in the group can delete the file. To prevent file deletion you have to deny directory write access to "mygroup". Or, set the "sticky" bit on the directory so that only the owner of the directory or owner of files in the directory can delete files.

Since the program is creating and writing a file, you also have to be careful of how symbolic links are handled in the directory. For example, if someone creates a symbolic link having the file name, then the program might write to a completely different file. To avoid that problem, set the "sticky" bit on the directory.

Although it is tempting to use "setuid" to run a program as "root" you should avoid doing that. Create a separate user account just for running the program. Give the user account only the minimum required permissions and group membership in order to do what it needs.

When a program creates files, the default is to create files owned by that user, and the primary group of that user. Set the user's primary group to the group that you want to own the files it creates. You can add other groups for the user as secondary groups to allow access to files belonging to those other groups.
 
Old 04-28-2013, 02:43 PM   #4
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Original Poster
Rep: Reputation: 0
I've written a C++ program and given it the user stick bit (chmod u+s). I can confirm that when the group user (505) runs the application their effective userid is the owner (503) by doing this:

Code:
cout << geteuid() << endl
As expected, it outputs 503 (the file owner).

However, if I execute the program as 505 (the group user) and have it try to open a file owned by 503 using ofstream, I get a permission denied error. When executed by 503, the program runs and the file opens just fine with ofstream.

When using system() in the program to run a shell script which echos $UID it displays "505" instead of the expected "503".

Why is it that the program runs as the owner but cannot then write to files or run programs as that user? It reverts back to 505.

Last edited by Karmaflute; 04-28-2013 at 03:41 PM.
 
Old 04-28-2013, 02:48 PM   #5
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,630

Rep: Reputation: 495Reputation: 495Reputation: 495Reputation: 495Reputation: 495
Quote:
Originally Posted by chrism01 View Post
I think you'd have to use suid if this was a binary, causing the program to run as the program user, not as the user.
However, suid is not honoured by the kernel for scripts, due to security issues.
Running a script is the same as running the cmds yourself, so I'm not sure you can accomplish what you want.
Perhaps if you told us why you think you need this ie what are you trying to achieve.

You could try using inotifywait to change the file ownerships upon creation http://linux.die.net/man/1/inotifywait.
See here http://www.linuxquestions.org/questi...364/page2.html
question, for something like that could he use su -c user "foo" to execute something as an other user? or would that require the script to originally be run as root or with an expect script passing the other users password in plane text?
 
Old 04-28-2013, 03:03 PM   #6
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Original Poster
Rep: Reputation: 0
User 505 does not have permission to run applications owned by 503. I use the u+s sticky bit to allow 505 to execute a program owned by 503 "as" 503 using group permission and the user stick bit.
 
Old 04-28-2013, 04:18 PM   #7
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 816

Rep: Reputation: 254Reputation: 254Reputation: 254
Quote:
Originally Posted by Karmaflute View Post
When using system() in the program to run a shell script which echos $UID it displays "505" instead of the expected "503".
Does the program call the function "setuid(503)" before running the shell script? Without that I believe that any child processes will have the real user ID, 505 instead of the program's user ID.
 
Old 04-28-2013, 04:22 PM   #8
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Original Poster
Rep: Reputation: 0
I tried that. Even though geteuid() returns 503, getuid() still returns 505 despite calling setuid(503) in the actual C++ code. The sticky bit automatically sets the effective user id (geteuid()) but not the actual user id (setuid()). setuid() is supposed to set this but it does not.

Edit:

I've found that by calling this:

Code:
setreuid(geteuid(), -1)
I can set the real user id to the effective userid (what I'd expected setuid() to do). Now both geteuid() and getuid() return 503 (the file owner) rather than 505 (the group user executing the program).

However, I am still unable to write to a file owned by 503.

Any other suggestions?

Last edited by Karmaflute; 04-28-2013 at 04:28 PM.
 
Old 04-28-2013, 04:38 PM   #9
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Original Poster
Rep: Reputation: 0
I was wrong. setreuid() did indeed fix the problem; I had a typo which made it appear as if the problem persisted.

I am using CentOS 6.4. It's possible that for security reasons it requires applications to explicitly set themselves to the real user id rather than the effective user id to take advantage of the sticky bit.

The solution in c/c++ is to use setreuid(). Is there alternative to this function for use in bash scripts?
 
Old 04-28-2013, 04:43 PM   #10
PTrenholme
Senior Member
 
Registered: Dec 2004
Location: Olympia, WA, USA
Distribution: Fedora, (K)Ubuntu
Posts: 4,186

Rep: Reputation: 346Reputation: 346Reputation: 346Reputation: 346
Consider setting up a process to write the file and using dmesg request the process to write the data. The write message would need to include the pid of the requesting process, and it could do some confirmation processing (sending additional messages as needed) to confirm that the requesting process is one authorized to write to the file.

In this approach, only the daemon would actually need the write permission, not the script or user. (The script could start the daemon with a suid if necessary, but you could start it as a system service during boot, and have it wake up when dmesg needed it.)
 
Old 04-28-2013, 04:55 PM   #11
Karmaflute
LQ Newbie
 
Registered: Oct 2010
Posts: 10

Original Poster
Rep: Reputation: 0
I'm already doing something similar with a poll script and a queue file. The problem is that if I were to allow scripts to write to the queue with group permission then I would have to give the group itself permission to write to the queue; which is a security hole if I want to restrict which users in the group get to send which commands to the queue.

By using the sticky bit on a file which only its owner has permission to write to the queue, I can effectively close this loop. I can then limit which users can access which commands by setting permissions on the sticky-bit file. Only users who can run this file get to write to the queue.
 
Old 04-28-2013, 05:32 PM   #12
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 816

Rep: Reputation: 254Reputation: 254Reputation: 254
Probably only "root" can change the user ID, but that should not matter since the effective user ID should be used to determine file access permissions.

I have three other suggestions.

There is a "setfsuid( )" function that you can use to set the user ID for file accesses. You should not have to use "setfsuid( )" because "seteuid( )" should have set the file-system user ID.

Make sure that the script file does not have the "setuid" bit set. That could change the effective user ID back to 505 when running the script.

If you still cannot gain access the the file, make "root" the owner of the program. Then have the program call "setuid(503)" or "seteuid(503)". Using "setuid(503)" is preferred since it permanently reduces privilege.

Unfortunately I haven't written any Linux programs so I can't give you any advice from experience. There are quite a few explanations on the Internet of the various functions to set the user ID.

Last edited by Erik_FL; 04-28-2013 at 05:33 PM.
 
Old 04-28-2013, 07:35 PM   #13
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,258

Rep: Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328
You could also use sudo to enable the group to run the prog (or even a script) as a completely different user.
The output file would then be unavailable to the group, assuming it (file) has a different group setting as well.
 
Old 04-29-2013, 02:04 PM   #14
PTrenholme
Senior Member
 
Registered: Dec 2004
Location: Olympia, WA, USA
Distribution: Fedora, (K)Ubuntu
Posts: 4,186

Rep: Reputation: 346Reputation: 346Reputation: 346Reputation: 346
Quote:
Originally Posted by Karmaflute View Post
[...]which is a security hole if I want to restrict which users in the group get to send which commands to the queue.[...]
Why not create another group for that sub-group of users? There is no (practical) limit to the number of groups of which a user cane be a member.
 
Old 04-29-2013, 09:51 PM   #15
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,258

Rep: Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328
He also said
Quote:
but not be allowed to write to the file directly.
If they are in the group that runs the prog to create the file, normally they'd be able to access the file directly as well...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SETGID and Group READ/WRITE Permission Difference cheersvega Linux - Server 5 09-03-2012 05:57 AM
[SOLVED] Write permission for group in samba share mandyapenguin Linux - Newbie 8 01-19-2012 11:38 AM
Saving a file removes the group execute permission jsteel Linux - Server 1 05-24-2011 05:16 AM
Need to remove Group write permission . pinga123 Linux - Newbie 2 10-22-2010 05:59 AM
vfat partition - write permission for users group digitized_funk Linux - Newbie 8 03-19-2003 08:30 AM


All times are GMT -5. The time now is 09:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration