tech-userlevel archive

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

Re: setuid scripts

On Sat, Feb 14, 2009 at 06:31:36PM +0000, Christos Zoulas wrote:
> In article <>, Aleksej Saushev  
> <> wrote:
> >Alan Barrett <> writes:
> >
> >> On Sat, 14 Feb 2009, Aleksej Saushev wrote:
> >>> > I think you can run setuid scripts if you build a custom kernel with
> >>> > SETUIDSCRIPTS enabled.
> >>> 
> >>> Does it prevent symlink attack or simply disables the check?
> >>
> >> AFAIK it works properly, by passing the script to the shell using an
> >> open file descriptor, named via /dev/fd/${number}.  I have no idea why
> >> it's disabled by default.
> >
> >Any reason to keep it disabled?
> People who write setuid shell scripts usually don't know what they are doing?

At least modern shells don't substitute variables before analysing
the syntax.
With a really old /bin/sh passing arguments like '>/etc/passwd'
to a suid script would likely cause the password file to be deleted.

These days, provided all that almost all shell variable uses are in ""
and that most commands use -- to ensure dubious data isn't treated
as options (and you don't want gnu getopt() in your way either) I
don't believe there are any attack vectors against suid scripts.

Of course, a user doesn't need read access for a suid script (unless
they are the owner!).


David Laight:

Home | Main Index | Thread Index | Old Index