File unreadable by root?

[Why Tea]

I need the following for testing on a system
while logged in as root:

1) Is it possible to prevent root from reading
a file? (Tried "chmod 000" and it didn't work)

2) Is there a way to create file/directory
violation by root like in Windows?

/WT

[JT]

On 15/09/11 01:53, Why Tea wrote:
> I need the following for testing on a system
> while logged in as root:
>
> 1) Is it possible to prevent root from reading
> a file? (Tried "chmod 000" and it didn't work)

No, not possible. To prevent root user (which should never be used for
normal use of your computer, only for maintenance tasks) to read certain
data, you could consider encrypting this data. But not sure if that's
your issue.

> 2) Is there a way to create file/directory
> violation by root like in Windows?

Not sure what you mean here. But root can read, write and remove any
file or directory on Linux. Hope that answers your question.
> /WT


--
Kind regards, JT

[Rob]

This is obviously incorrect.

Try this: chattr +i filename

[Eef Hartman]

Why Tea <ytl...@gmail.com> wrote:
> 1) Is it possible to prevent root from reading
> a file? (Tried "chmod 000" and it didn't work)

For a local filesystem: no
The attributes are just for "normal users", there is no "root" in there.
For a NFS mounted fs with "root_squash" (default), root is just the
"anonymous" user on that, so without "read for others" it cannot read
ANY file mounted through NFS.

> 2) Is there a way to create file/directory
> violation by root like in Windows?

I've NO idea what you're talking about, but again: on local fs'es
root can do EVERYTHING on all files and directories as there are
no special attributes FOR root. Unlike windows "administrator",
root is not a normal user with "extra rights", but the SUPERuser,
allowed to do everything.
With ACL's you can add extra access rights to a file but as far as
I know NOT remove any rights for root.
--
******************************************************************
** Eef Hartman, Delft University of Technology, dept. SSC/ICT **
** e-mail: E.J.M....@tudelft.nl - phone: +31-15-27 82525 **
******************************************************************

[Eef Hartman]

Rob <nom...@example.com> wrote:
> Try this: chattr +i filename

The immutable attribute can be reset again BY the superuser, so
although it offers limited protection, it is not proof against the
superuser (like a hacker who gained root rights on your machine).

[JT]

On 15/09/11 11:13, Eef Hartman wrote:
> Rob<nom...@example.com> wrote:
>> Try this: chattr +i filename
> The immutable attribute can be reset again BY the superuser, so
> although it offers limited protection, it is not proof against the
> superuser (like a hacker who gained root rights on your machine).

That , PLUS the fact that it is immutable. Not unreadable. So root will
still be able to see the data - and the title of the OP is clear about
that question.

--
Kind regards, JT

[J G Miller]

On Thursday, September 15th, 2011 at 10:41:43h +0200, JT wrote:

> On 15/09/11 01:53, Why Tea wrote:
>> I need the following for testing on a system while logged in as root:
>>
>> 1) Is it possible to prevent root from reading a file? (Tried "chmod
>> 000" and it didn't work)
> No, not possible.

Not possible with chmod, but apparmor can be used to prevent processes
running as root from accessing directories or files, and no doubt
selinux can as well.

[John Bowling]

I don't know how it is done, but /home/user/.gvfs cannot be accessed by
Updateeb (of Locate) when in su mode.
Using la, that directory is listed at:
d????????? ? ? ? ? ? .gvfs

I also tried looking at it using Hex.
It cannot open or display even normal directories in user or su mode.

So it can be done, but no clues as to how.

John

[Eef Hartman]

John Bowling <johnl...@cox.net> wrote:
> I don't know how it is done, but /home/user/.gvfs cannot be accessed by
> Updateeb (of Locate) when in su mode.

.gvfs is managed by the (userspace) gvfsd daemon and is a "sort of"
mount point FOR gvfs:
GVFS[1] is the virtual filesystem for the GNOME desktop
So it is far from a "normal" directory, but more like the automount
directories, managed by the autofs component.

[unruh]

Then afterwards try
chattr -i filename

Then do chmod a+rwx filename
chmod a-rwx filename
rm filename

as root.

[Jan Kandziora]

Why Tea wrote:
>
> 1) Is it possible to prevent root from reading
> a file? (Tried "chmod 000" and it didn't work)
>

This is possible using SELinux, but only if no user has physical access to
the computer. Then he could always remove the harddisk and read it with
another computer. (If you try encryption, a malicious user with access to
the computer may tamper the keyboard and get the passphrase for the
encrypted files.)

> 2) Is there a way to create file/directory
> violation by root like in Windows?
>

You confuse MS-Windows "Administrator" and "LocalSystem" accounts.
Unix "root" is like MS-Windows "LocalSystem". MS-Windows "Administrators"
are like users in the Unix "wheel" group.

Kind regards

Jan

[Why Tea]

Thanks. I'm aware of this.

Thanks also for all other replies. I probably should
be more specific, I was looking for ways to test
some software. Once running as root, there seems to
be no such thing as a file or directory access violation.
That is, a root can delete a file even if it's being
edited. A directory can be renamed or mv'ed even if
someone else has cd'ed into it.

/WT

[unruh]

But the editor has opened it by inode, not name. rm just removes the
name from the directory. Thus when the editor saves it, it will probably
write a new name as well.

[Rob]

Why Tea <ytl...@gmail.com> wrote:
> Thanks also for all other replies. I probably should
> be more specific, I was looking for ways to test
> some software. Once running as root, there seems to
> be no such thing as a file or directory access violation.
> That is, a root can delete a file even if it's being
> edited. A directory can be renamed or mv'ed even if
> someone else has cd'ed into it.

Oh but those things are not privileged to root...
In Windows, files that are edited are usually being locked.
Unix editors usually don't do that.
And "being cd'd to a directory" does not lock it either.

You will find that "pwd" usually is an alias to a fast internal
function that echoes the path last cd'd to, but the oldfashioned
program /bin/pwd will print the directory path even when the
directory has been renamed after the cd.

[Paul J Gans]

Root has great power. With great power comes great responsibility.
Root can, indeed, screw up the entire machine, and do it much more
simply than renaming files in use.

Windows is different. The Administrative user has certain abilities.
But above the administrative user is the Windows Nanny. Thwarting
the Nanny isn't easy. That can protect you in some situtations.
And it can ruin your day in others.

--
--- Paul J. Gans