[lkml]   [2001]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Overriding qouta limits in Linux kernel

Sorry for delayed reply..

> > has a CAP_SYS_RESOURCE capability then it can override the limits (that's
> > how I understand this capability). Hence it's got right to exceed user quota.
> > I think this is reasonable behaviour (root can do anything - suid binaries are
> > just making the will of root ;)).
> > And BTW I know about no way how to know who opened the file...
> It is ok if suid binaries do what they are privileged to. But it is not ok
> if unprivileged users do what they want using privileges of those suid
> binaries.
I was thinking about it and you're right that probably exceeding quota by
SUID programs usually isn't behavior which is useful. On the other hand I find
for example testing ability to override quota on open a bit against the design.
The design IMHO is: everytime process wants to allocate some space on disk check
whether he's got right to do so... So quotas aren't per file thing and with this
is connected another technical problem - quota know nothing about who's opened
the file. Everything it's got is an inode and an amount of space current process wants
to allocate to that inode. So it's a problem to make quota code do decissions
based on the opener of the file.

> Controling qouta is not a user-space task. Kernel should perform some
> additional checks before allowing suid binary to write to file descriptor
> that is inherited from unprivileged user process.
I agree that this is a problem and it has to be solved in kernel.

> Good solution is to check CAP_SYS_RESOURCE process's capability when the
> file descriptor is opened (just like CAP_DAC_OVERRIDE and
> others are checked).
See above.. It's not that easy...

Jan Kara <>
SuSE CR Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:12    [W:0.062 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site