Linux - NewbieThis 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
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am a user of a cluster. I don't want root to see/copy files from my user account(obviously).
Is that possible to limit the access of root to users account?
I am a user of a cluster. I don't want root to see/copy files from my user account(obviously).
Is that possible to limit the access of root to users account?
In Unix-style computer operating systems, root is the conventional name of the user who has all rights or permissions (to all files and programs) in all modes (single- or multi-user). Alternative names include baron in BeOS and avatar on some Unix variants. BSD often provides a toor (“root” backwards) account in addition to a root account for better usability while performing administrative tasks. Regardless of the name, the superuser always has zero user ID. The root user can do many things an ordinary user cannot, such as changing the ownership of files and binding to network ports numbered below 1024. The etymology of the term may be that root is the only user account with permission to modify the root directory of a Unix system.[2]
So if there is problem with files being viewed by root/superuser then I suggest an alternate storage of your secure files that can be removed from the system.
There is the need for a root/superuser to be able to master control the environment of the system. If the superuser cannot be trusted then move to another system to find a trusted superuser. 'paranoia' is fine at times but this is not one.
well, in that case, I need to keep my files encrpted...so that root cannot see this.
take the file:
Quote:
$ cat trial.sh
#!/bin/bash
echo "Hello World"
if i am trying to encrypt this:
Quote:
$ gpg -c trial.sh
it asks for passphrase and ends up with:
Quote:
$ gpg -c trial.sh
can't connect to `/home/rudra/.gnupg/S.gpg-agent': No such file or directory
and then:
Quote:
$ chmod 700 trial.sh.gpg
$ ./trial.sh.gpg
5�-��P�: command not found
./trial.sh.gpg: line 2: unexpected EOF while looking for matching ``'
./trial.sh.gpg: line 4: syntax error: unexpected end of file
This won't work; the shell has no idea what an encrypted file is,
and just like root it can't see "the real thing" - the commands
in the encrypted file.
To make the shell run it, decrypt it.
What exactly is your issue with root potentially seeing your
script, anyway? He's either the owner of the machine, or by
the owners will empowered to the ability to see all files.
If you don't want him to look at your files, don't store them
on his machine.
What exactly is your issue with root potentially seeing your
script, anyway? He's either the owner of the machine, or by
the owners will empowered to the ability to see all files.
yes....but i am afraid he is making mess with my codes
Use a virtual machine and enable encrypted file system. As you are the root of vm nothing can be done inside vm without your permission. Use of proper encryption policy will ensure that nothing can be done outside vm. (Eg. Boot time password, Boot loader password, Efs etc.).
Now you can work seamlessly with your files without have to decrypt them every time.
Only thing root can do is delete your files, or vm all together, but she cant mess with them.
You can use QEMU(widely available) for this purpose.
This last suggestion is interesting, but it's important to understand that root would always find a way to access your files, no matter what you do. The "easiest" way in the vm scenario would be to capture your keyboard input, either in the input-layer kernel driver for the local keyboard, or by modifying sshd (or whatever is used for remote access).
Of course, this is VERY paranoid, I just mention it to illustrate that it's a bad idea to use a system where you can't trust "root" to respect your privacy.
To ensure security you have to work hard, specially when the scope of trust is small.
There are ways , which i cant mention here (the moderator once scolded me for similar reasons), to do that. It is up to you to find them.
yes....but i am afraid he is making mess with my codes
How do you know this?
You sure it's not you or someone else with equivalent access?
As superuser most will do everything to the 'T' to prevent problems with a system. If a user does something that is not allowed then the 'superuser' will normally warn before any action(s). If the person doesn't adjust or correct their ways then most 'superuser' will just lock the violator out.
Distribution: Ubuntu 11.4,DD-WRT micro plus ssh,lfs-6.6,Fedora 15,Fedora 16
Posts: 3,233
Rep:
just to add my 2 cents i would have to agree with all the above posts that if you are afraid of root messing with your scripts then don't keep them on that machine since linux/unix systems were designed from the ground up for root to have full acess to the system, if you are afraid he/she will mess things up then simply keep a backup, which would be good practice anyways. root access trums user security access, and physical access trumps BOTH so it all comes down to trusting the powers that be or not using the system, period.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.