Re: [PATCH] implement privmode support in dash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 22, 2013 at 1:35 PM, Jilles Tjoelker <jilles@xxxxxxxx> wrote:
> I think there is no reason to deviate from other shells here. Therefore,
> please call it "privileged".
>

Agreed.

>> In bash and FBSD, after starting with -p, set +p can be used to drop
>> privileges. With your patch, dash accepts set +p, but silently ignores it.
>
>> How does something like the attached, to be applied on top of your
>> patch, look?
>
>> [snip]
>> +     if (!on && (uid != geteuid() || gid != getegid())) {
>> +             setuid(uid);
>> +             setgid(gid);
>> +             /* PS1 might need to be changed accordingly. */
>> +             choose_ps1();
>> +     }
>> +}
>
> This code tries to use setuid() and setgid() to drop all privilege,
> which is only correct if the privilege to be dropped is UID 0, or on BSD
> systems. It would be better to use setresuid() or setreuid(), and change
> the GID before changing the UID.

This is logic duplicated from pdksh and bash, I'm slightly reluctant
to do things differently, unless it's not going to get committed
otherwise.

You can see some code snippets here:
http://blog.cmpxchg8b.com/2013/08/security-debianisms.html

> Apart from that, it is better to check the return value from setuid()
> and similar functions. In particular, some versions of Linux may fail
> setuid() for [EAGAIN], leaving the process running with the same
> privileges.

I don't think this is true anymore, but I have no strong objection to
adding it, so long as it's noted that bash and pdksh do not do this.

Tavis.
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux