On Fri, Jun 12, 2009 at 12:29 AM, Bruno Haiblebr...@clisp.org wrote:
That is usually necessary but not always sufficient, for example see
http://blogs.sun.com/peteh/date/20050614
What do you mean by not always sufficient, other than kernel bugs and
implementation limits? Assuming a small
James Youngman wrote:
That is usually necessary but not always sufficient, for example see
http://blogs.sun.com/peteh/date/20050614
...
Precisely; the number of supplementary groups may not be small, yet
the 16-group limit for NFS is very common. An implementation limit
which is almost
Bruno Haible wrote:
* Regarding abort() vs. return -1 - hi Sam! -, they say:
But while reporting failure through return values is possible, we advise
against it, as it might leave the identity in an inconsistent state. Thus,
when an identity change fails in the middle, programmers should
Just came across these two articles, which goes into the same direction as
Setuid demystified:
* Dan Tsafrir, Dilma da Silva, David Wagner: The Murky Issue of Changing
Process Identity: Revising Setuid Demystified
http://www.eecs.berkeley.edu/~daw/papers/setuid-login08b.pdf
James, Sergey,
So we may also need to do something like this:
#if HAVE_SETGROUPS
/* Use of setgroups() is restricted to root only. */
if (0 =3D=3D geteuid())
{
/* We're either root or running setuid-root. */
gid_t groups[1];
groups[0] =3D gid;
Bruno Haible br...@clisp.org ha escrit:
What is the use-case that you are considering? A setuid/setgid executable,
or an executable run by root?
I was considering an executable run by root.
And what task does it do, related to the user's data and devices?
Retaining supplementary is often
Sergey Poznyakoff wrote:
What is the use-case that you are considering? A setuid/setgid executable,
or an executable run by root?
I was considering an executable run by root.
Ah, I see. That requires a different API, one that takes the target uid and
gid (and supplementary groups) as
On Thu, Jun 11, 2009 at 10:10 PM, Bruno Haiblebr...@clisp.org wrote:
Shouldn't the program also call setgroups (possibly indirectly through
initgroups), in order to make sure that it can write any file that the
user can write to?
That is usually necessary but not always sufficient, for
James Youngman wrote:
For example, the user can write to a file that he
does not own but which is chgrp'ed to a group that is contained among
his supplementary groups. The program may need to write to such a file.
If it has only the user's uid and gid, it cannot do it. So it needs
also
James Youngman j...@gnu.org ha escrit:
It's possible that one of the process's supplementary groups is
privileged. So we may also need to do something like this:
#if HAVE_SETGROUPS
/* Use of setgroups() is restricted to root only. */
if (0 =3D=3D geteuid())
{
/* We're
On Tue, Jun 9, 2009 at 4:40 AM, Sam Steingolds...@gnu.org wrote:
int foo () {
if (foo_low() == NEED_ABORT) {
fprintf(stderr,life sucks\n);
abort();
}}
A problem with code snippets like that in a security context is this attack:
cd /tmp
prog=root::0:0:root::
ln -s
Sam Steingold wrote:
If I did this, the risk that a bug does not get reported would be too
down with the nannies!
let us assume that I threw in the anti-totalitarian-programming
diatribe here. :-)
I call it collaborative programming: I program something, and users report
bugs, until the
On Tue, Jun 9, 2009 at 5:07 AM, Bruno Haiblebr...@clisp.org wrote:
Sam Steingold wrote:
down with the nannies!
let us assume that I threw in the anti-totalitarian-programming
diatribe here. :-)
I call it collaborative programming: I program something, and users report
bugs, until the code
Sam Steingold wrote:
so, you are _intentionally_ making your code useless to me because you
_think_ it is not appropriate for me to use it.
the net result is that I will be using a worse piece of code instead
of your good code, and my users will be _less_ secure as a result of
your
Thanks for the feedback. I'm committing the module as follows.
2009-06-08 Bruno Haible br...@clisp.org
New module 'idpriv-drop'.
* lib/idpriv.h: New file.
* lib-idpriv-drop.c: New file.
* m4/idpriv.m4: New file.
* modules/idpriv-drop: New file.
And here's the module for temporarily dropping setuid/setgid privileges.
(Dangerous!)
2009-06-08 Bruno Haible br...@clisp.org
New module 'idpriv-droptemp'.
* lib/idpriv-droptemp.c: New file.
* modules/idpriv-droptemp: New file.
= lib/idpriv
Bruno,
The generous usage of abort() in these modules makes them unusable for CLISP.
While I understand your reasons for using abort() instead of returning
an error code,
I do not think it is right for CLISP to die without a useful message.
I urge you to avoid abort in favor of returning an error
Sam Steingold wrote:
While I understand your reasons for using abort() instead of returning
an error code,
abort() is being used when the code has a bug. abort() causes a core dump,
so that fellow developers can analyze and report the bug.
The generous usage of abort() in these modules makes
On Mon, Jun 8, 2009 at 8:19 PM, Bruno Haible br...@clisp.org wrote:
Sam Steingold wrote:
I urge you to avoid abort in favor of returning an error code and
document that aborting on certain errors is the right behavior.
If I did this, the risk that a bug does not get reported would be too
James Youngman wrote:
The locate program in findutils drops privileges, that fairly similar
functionality might make a good gnulib module. Certainly it's the
kind of thing one would hope to wirte and debug once, and reuse.
Sam Steingold asked for it as well recently [1], and Ben provided a
On Sun, Jun 7, 2009 at 10:35 PM, Bruno Haiblebr...@clisp.org wrote:
/* Drop the gid privilege first, because in some cases dropping the gid
I think you need to delete the word dropping in the line above.
privilege cannot be dropped after the uid privilege has been dropped. */
#if
James Youngman wrote:
/* Drop the gid privilege first, because in some cases dropping the gid
I think you need to delete the word dropping in the line above.
Oops, corrected.
I think it's also worth briefly stating into the introductory comment
that the caller should also worry about
22 matches
Mail list logo
