448191 Posted November 22, 2007 Share Posted November 22, 2007 I accidently did: $ rpm --help > grep ...and what do I find? The rpm help output gets written to /bin/grep... Byebye grep. I thought: why does anything in /bin and /usr/bin need write permissions anyway? I was caught off guard, expecting some sort of failsafe. So I chmodded /bin to 551, expecting not to be able to write on files in /bin. But I was perfectly able to create a file in /bin, edit it, remove it. So what's up with that? Does it have anything to do with operating as root? Do I really need to apply permissions on all files? Quote Link to comment Share on other sites More sharing options...
rajivgonsalves Posted November 22, 2007 Share Posted November 22, 2007 well the root user is a super admin so possible can do anything... therefore its adviced to create another account with less permission and use that account. Quote Link to comment Share on other sites More sharing options...
trq Posted November 22, 2007 Share Posted November 22, 2007 If you chmoded /bin to 551 you should not be able to create a file within it. You could still however edit anything within /bin that was writtable. Something does seem whack to me. The lesson here however is don't work as root. There is simply no need. Quote Link to comment Share on other sites More sharing options...
448191 Posted November 22, 2007 Author Share Posted November 22, 2007 If you chmoded /bin to 551 you should not be able to create a file within it. Well.... $ # ls -l ... dr-xr-x--x 2 root root 4096 Nov 22 12:40 bin ... $ # touch /bin/testfile3 $ # ll /bin/testfile3 -rw-r--r-- 1 root root 0 Nov 22 13:41 /bin/testfile3 $ # You could still however edit anything within /bin that was writtable. Something does seem whack to me. I really don't get it. Do you see a 'w' in /bin's permissions? $ # rm /bin/testfile3 $ # ll /bin/testfile3 ls: cannot access /bin/testfile3: No such file or directory $ # ll / total 92 dr-xr-x--x 2 root root 4096 Nov 22 13:47 bin drwxr-xr-x 3 root root 4096 Nov 21 14:39 boot drwxr-xr-x 12 root root 7120 Nov 22 10:04 dev drwxr-xr-x 92 root root 12288 Nov 22 11:46 etc drwxr-xr-x 4 root root 4096 Nov 21 14:51 home drwxr-xr-x 11 root root 4096 Nov 21 14:37 lib drwx------ 2 root root 16384 Nov 21 14:06 lost+found drwxr-xr-x 3 root root 4096 Nov 22 10:04 media drwxr-xr-x 2 root root 4096 Sep 22 00:04 mnt drwxr-xr-x 3 root root 4096 Nov 21 14:08 opt dr-xr-xr-x 116 root root 0 Nov 22 11:03 proc drwx------ 8 root root 4096 Nov 22 13:50 root drwxr-xr-x 3 root root 12288 Nov 21 14:33 sbin drwxr-xr-x 4 root root 4096 Nov 21 14:07 srv drwxr-xr-x 11 root root 0 Nov 22 11:03 sys drwxrwxrwt 13 root root 4096 Nov 22 13:45 tmp drwxr-xr-x 13 root root 4096 Nov 21 16:45 usr drwxr-xr-x 14 root root 4096 Nov 21 14:10 var drwxr-xr-x 3 root root 4096 Nov 21 14:07 windows The lesson here however is don't work as root. There is simply no need. What do you suggest? Should I make a seperate user and chown dirs and their contents needed for sysadmin to it? I'm not using root as a regular user account, if that's what you're saying. I'm trying to install stuff, setup services, system variables etc. So I need the su command. Quote Link to comment Share on other sites More sharing options...
effigy Posted November 27, 2007 Share Posted November 27, 2007 I accidently did: $ rpm --help > grep ...and what do I find? The rpm help output gets written to /bin/grep... Byebye grep. I would never work in the bin directory. Isn't rpm in your path? Quote Link to comment Share on other sites More sharing options...
448191 Posted November 27, 2007 Author Share Posted November 27, 2007 I accidently did: $ rpm --help > grep ...and what do I find? The rpm help output gets written to /bin/grep... Byebye grep. I would never work in the bin directory. Isn't rpm in your path? You've got a point. Lesson learned. Though I still don't get it: are file permissions inherited from parent dirs or not? Quote Link to comment Share on other sites More sharing options...
effigy Posted November 27, 2007 Share Posted November 27, 2007 The following are how directory permissions function: r: Allows the contents to be listed. w: Allows creation/removal of files/directories. x: Allows cd and/or usage within a path. These mean nothing if you're root, though. Quote Link to comment Share on other sites More sharing options...
448191 Posted November 28, 2007 Author Share Posted November 28, 2007 The following are how directory permissions function: r: Allows the contents to be listed. w: Allows creation/removal of files/directories. x: Allows cd and/or usage within a path. That I knew. These mean nothing if you're root, though. That I didn't know. I figured that even as root, you'd need to set the right permissions. I guess not. I hate it, but it answers my question. Mucho gratio. Quote Link to comment Share on other sites More sharing options...
448191 Posted November 28, 2007 Author Share Posted November 28, 2007 Wait a sec, so not setting the 1 in octal doesn't effect the 1's in the files in that dir? Light bulb moment.. Did I get it? r: Allows the contents to be listed. ie: use ls and the like? x: Allows cd and/or usage within a path. You'd need this to reference files in the dir. Without it, the directory's contents are inaccesable. You can list them if you have r, but you can't do anything with them. If I have x, I can access files in the dir and modify or execute them, right (or does modify actually go with w (2))? w: Allows creation/removal of files/directories. This is complementary to x (octal 1), right? If you don't have x (1) on a dir, the w (2) is useless? I can't create files that I can't reference, right? Quote Link to comment Share on other sites More sharing options...
effigy Posted November 28, 2007 Share Posted November 28, 2007 The directory permissions are still separate from the file permissions. For instance, if you do not have access to write in bin, there's no use to check the permissions of grep. If you do have permissions, then it goes on to check if you have write access on grep, and if so, overwrites the file. Since root is the superuser it always has access to everything. Another move towards preventing this in the future is to see if your shell supports a noclobber option. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.