Re: VI wrapper for SUDO? - another bad way ??
Gerfried Fuchs writes:
>* William R Ward <email@example.com> [2001-12-03 00:50]:
>> Right; but assuming one takes care of this kind of issue, is there
>> anything inherently unsafe about running shell scripts through sudo?
> shell scripts usually call other programs - whose behavior could be
>most of the time changed with env-variables. It's almost impossible to
>think of all those things.
Yes, it is difficult, but if one is conscientious enough about
checking all the environment variables and such it can be done.
>> I understand that there are risks of race conditions with setuid shell
>> scripts, and so they are disabled on most Linux boxen.
> You have a misinformation/misinterpretation there. It's not disabled,
>it's simply not possible in the way scripts are run. They are passed to
>the program that is given in it's first line, after the #! - or to the
>current shell, if there is no such line. As *argument*.
> If you think about it how should the suid/sgid bit from an argument be
>given over to the program which handles that file? There's no way other
>than using wrappers, like sudo.
It's been an option on traditional Unix systems for a long time. When
kernel runs the interpreter listed on the #! line, it does so with
suid/sgid access enabled. It's not really any more difficult than
launching binaries. It's the kernel, not the shell, that parses the
#! line. I'm not sure in what ways Linux may differ from traditional
Unix on this point, however.
>> Is that also an issue for sudo shell scripts?
> You should give sudo access to a shell script only to those persons who
>you trust. After all, think about it - is root really needed there?
>Most parts don't really need root but can be done through group usages,
>like most things in Debian works. That gives you another level of
A lot of things, like sendmail for a prominent example, may use group
accounts but still expect the files to be owned and writable only by
> Btw, why was this mailed to debian-security? I don't see anything
>related to debian in that, some general linux (security)
>mailinglist/newsgroup would suit better.
Because the thread originated there. The original idea was
debian-related, in that I wanted to be able to have /etc/alternatives
be consulted when deciding what editor to invoke.
William R Ward firstname.lastname@example.org http://www.wards.net/~bill/
If you're not part of the solution, you're part of the precipitate.