[lkml]   [1996]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Proposal: restrict link(2)

    On Wed, 11 Dec 1996, Greg Alexander wrote:

    > Date: Wed, 11 Dec 1996 23:00:01 -0500 (EST)
    > From: Greg Alexander <>
    > To: Linux kernel mailing list <>
    > Subject: Re: Proposal: restrict link(2)
    > On Wed, 11 Dec 1996, Hubert Mantel wrote:
    > However, for small code-hackers, who do all sorts of funny things to their
    > systems, finding a single linux partition with all of the files on it is a
    > _very_ common thing. security should not be denied to these systems.

    Well, if you only have one filesystem you have a problem. And small code
    hackers with only one drive generally are not runing highly-secure systems.
    There are some that I know of, but not many.

    > However, I don't think that this is necessarily a kernel issue.
    > If compatability is hoped to be maintained with more "standard" flavors
    > then the commands should probably continue to work basically the same. It
    > presents a problem that can and should be easily solved in userspace.

    _NO_ There are _WAY_ too many buggy programs out there... and unless you
    are willing to be on 20-30 security lists and are quite capible of fixing
    on the spot any program that you are running on your system... not just
    suid stuff, but anything that is called from cron, that is a server, or
    that root may run, then you will need some sort of kernel help on this.

    > Having the kernel take care of everything adds to all sorts of
    > portability/security problems on other platforms. Even the way that some

    Actually, the inability to link to files owned by someone else isn't
    really a major problem... I can't really see any time that you would
    need to link() to a file that you only have read access to. If you
    can write to it (owner/group/other) then you should be able to link to it.
    Besides, by link()ing to a file you change it. And if you don't have the
    ability to write to it, you should _NOT_ be able to change a file.
    symlinks don't count, as they are just pointers to a file that may, or may
    not exist. Hard links become the file itself.

    > of the includes include other stuff automatically for me has proven to be
    > a pain in the butt when trying to port to SunOS (am I seeing funny
    > systems, or is every SunOS system's include files really messed up?).
    > Being able to assume that there are no hardlinks in /tmp that shouldn't be
    > there is not an assumption that I think programs should be able to make.

    All too true. But all too common none the less...

    Would anything BREAK if we made link() depend on write access? And does
    POSIX require that ability?

    NOTE: I'm not saying this should be the default behavior. And nobody can make
    the argument that it 'promotes stupid security errors' Because it dosn't.
    What it _DOES_ is fix the hole that lots of stupid programmers make. And just
    doing a stat() before modifying a file may not be good enough... that does
    leave fairly obvious race conditions. Besides, I don't like the idea of
    someone leaving a program that watches /tmp for "interesting" files, then
    hardlinks them before they get erased... If they can make something permanant,
    they may be able to use something else to get at it. For example, some hole in
    some cron'd process that only execute sonce per hour... what's the odds of a
    password change that puts a copy of /etc/shadow in /tmp happining at the exact
    time that does? But if they can link("/etc/shadowtmp","/etc/mytmp"); then
    they can come back and read it at their leasure...

    Now, like I said, do we _REALLY_ like the connotations of being able to link
    (and therefore modify) files that we don't have write permissions to?


     \ /
      Last update: 2005-03-22 13:38    [W:0.021 / U:27.776 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site