Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a folder that normally lives under /root and is usually used by a root user. I need to allow another user (other than root) to use it now, but it has to remain under /root. Is that possible?

EDIT: Thanks everyone for the comments and help. We do understand the security reprecussions of this and fully understand what we are asking for. So removing all security concerns aside, what is one way to do that. Thank you.

share|improve this question
2  
What is the real limitation here? Hard coded paths in a program? A file system mounted at /root? Backup scripts? What's the hang up that dictates that a user accessible data set live in /root? Maybe knowing the real limitation we can suggest a better system and you can talk the client into using it. –  Caleb Jun 7 '11 at 9:16
    
It is hard coded values in a java application. We need to add this fix asap, until we release a new version of the application. –  mjouni Jun 7 '11 at 9:38
    
In that case none of our ninja tricks will work, your only option is to be really really stupid (see my edited answer) and make a fuss about it being temporary. Have a cron job send warnings to your boss every day about permission problems detected on the system. –  Caleb Jun 7 '11 at 9:46
    
@mjouni: I removed the word "stupid" from my answer. However I don't think you need to take this personally. Of course I have written my share of really stupid code. I've had boxes compromised for doing just what you're having to do. I've hard coded paths. And I've had my co-workers tell me those were stupid things to do and learned to fix them. Of course when a question gets asked we don't know the full background, but it you come here looking for a solution that requires a bad-practice, this community will first offer the best solution and require you to defend your need for a hack. –  Caleb Jun 7 '11 at 11:10
    
Also, please move the social commentary out of your question and into a comment since it isn't relative to the problem and doesn't belong archived along with it. Well taken, but should be a comment not part of the question for future readers. Thanks :) –  Caleb Jun 7 '11 at 11:13

2 Answers 2

up vote 6 down vote accepted

First of all, you are Doing It Wrong™. There is something fundamentally wrong with the way you are trying to go about this. Your software will be better off if you try to understand the normal unix security and permissions model and work WITH it instead of fighting/breaking it.

The only way I can think of to do what you want without blowing a thousand holes in the file system permissions is to set the folder in question up with a group and group-based permissions, then mount it somewhere else using a bind-mount so that it can be accessed by a user-accessible path instead of inside /root. The data can stay there, but non root users shouldn't be able to stick their head in there, so it needs a handle elsewhere in the file system. You can't symlink to it beccause that will just route you back through /root, but a bind mount setup ahead of time by root should provide an alternate path that it can be reached by as a non-root user.

Edit: In the case clarified in comments of having an application with a hard coded path, none of the things I or Alkdae suggest will actually work. As a temporary work around, I suggest making sure anything in root that is sensitive such as /root/.ssh is owned as root:root and marked as 0600 or other such restrictive permissions. Then move anything in /root that doesn't need to be there into a subfolder such as /root/root_files and make sure that is root:root 0600 too. Once you are sure there is nothing there to be seen or exploited, set the group ownership on /root to some special group like temproot and set it to be browsable by that group (but NOT world or the normal users group!). Then add your special users to that group, and set the files in /root used by that java app as owned by root:temproot with group write/execute permissions as appropriate.

As soon as you can fix the offending java app, chown everything in root back to root:root.

share|improve this answer
    
I understand how nuts this request is from a security standpoint. But this is something we have to do for a client, and they know the security repercussions. –  mjouni Jun 7 '11 at 9:08
1  
@mjouni: No they don't or they wouldn't make you do this! –  Caleb Jun 7 '11 at 9:15
1  
I'd prioritise rebuilding the Java app to be less stupid way above posting on Serverfault asking how to cripple the security of a system. How long would it actually take to check out the source, change the filepaths and rebuild it? –  Tom O'Connor Jun 7 '11 at 10:14
2  
It may well not actually be the hardcoded paths that M. mjouni claims it to be. Consider the case of an application that dumps files into $HOME that, for whatever reason, in this case has to be run from a superuser login. In such a case, it's not a simple case of checking out the source and changing a string. It's checking out the source and fixing all of the bad design that forces the application to be run as the superuser in order to actually work. Of course, conversely, it could equally be the case that just tweaking the application's $HOME with a wrapper script would fix this. –  JdeBP Jun 7 '11 at 10:54

You can move the folder outside of /root and create a link to it. That way you will still have it in your folder and you can set permissions for others to access it.

Allowing others to see inside /root is just plain wrong.

share|improve this answer
1  
+1 for doing this backwards with the data elsewhere and linked from inside root, but this might not fit the users bill, particularly if part of the reason it "has to be" inside root is for partition mounting, backups or other file location sensitive issues. –  Caleb Jun 7 '11 at 9:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.