does e2fsprogs needs to invoke file system related system calls?

does e2fsprogs needs to invoke file system related system calls?

[Xin Zhao]

does e2fsprogs needs to invoke file system related system calls?

The reason I want to ask this question is to know whether we can
bypass the system call monitoring based access control with e2fsprogs.

Thanks
-x

Re: does e2fsprogs needs to invoke file system related system calls?

[Theodore Ts'o]

On Thu, May 05, 2005 at 04:49:33PM -0400, Xin Zhao wrote:
> does e2fsprogs needs to invoke file system related system calls?
> 
> The reason I want to ask this question is to know whether we can
> bypass the system call monitoring based access control with e2fsprogs.

You'll need to be more specific about exactly what you are asking and
why.  Of *course* e2fsprogs needs to invoke filesystem related system
calls.  Just to give a few examples: e2fsck uses the blkid library to
map from a LABEL specifier to a device, and this libblkid will open
and read /etc/blkid.tab; e2fsck will open and read the /etc/mtab file
to make sure it is not checking a mounted filesystem; e2fsck will need
to open the block device and then read and write from said block
device.  If libntl are in use, then of course e2fsprogs will have to
open and read the translation files from the filesystem --- and this
is just the surface.

							- Ted

Re: does e2fsprogs needs to invoke file system related system calls?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

On Thu, 05 May 2005 16:49:33 EDT, Xin Zhao said:
> does e2fsprogs needs to invoke file system related system calls?

Which calls do you mean?  I suspect that for the most part, it's
doing read/write/etc to the *underlying medium* - for instance, mkfs.ext3
can't use calls related to the *file system* because it's not mounted
yet (it doesn't even *exist* yet).

> The reason I want to ask this question is to know whether we can
> bypass the system call monitoring based access control with e2fsprogs.

It's been known since the Unix V7 days and even earlier that having read/write
access to the underlying /dev/hd-whatever partition was able to bypass
file permissions on the file system built on that partition.  Of course, write
access is at your own risk, as there's no easy/clean way to ensure that the
kernel doesn't have an in-core copy that doesn't match what you wrote (as
everybody who's run fsck on a live file system can testify ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]