Why sticky bit on executables? - SCO

This is a discussion on Why sticky bit on executables? - SCO ; Hello. As I was in the process of changing the default shell from /bin/sh to /bin/ksh in an OperServer 5.0.7 test machine, I noticed the /bin/sh binary had the sticky bit set: # ls -l /bin/sh lrwxrwxrwx 1 root root ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Why sticky bit on executables?

  1. Why sticky bit on executables?

    Hello.

    As I was in the process of changing the default shell from /bin/sh to
    /bin/ksh in an OperServer 5.0.7 test machine, I noticed the /bin/sh
    binary had the sticky bit set:

    # ls -l /bin/sh
    lrwxrwxrwx 1 root root 30 Jul 1 21:11 /bin/sh -> /opt/K/SCO/Unix/5.0.7Hw/bin/sh
    # ls -l /opt/K/SCO/Unix/5.0.7Hw/bin/sh
    -rwxr-xr-t 1 bin bin 59536 Feb 18 2003 /opt/K/SCO/Unix/5.0.7Hw/bin/sh

    It picked my curiosity, so I wanted to know what other non-directories
    had the stick bit set in the system:

    # for var in `find / -perm -u+t` ; do ls -ldF $var ; done | grep -v /$
    -rwx--x--t 1 bin bin 170876 Jul 1 20:47 /opt/K/SCO/Unix/5.0.7Hw/usr/bin/euc/vi*
    -rwx--x--t 1 bin bin 151512 Jul 1 20:47 /opt/K/SCO/Unix/5.0.7Hw/usr/bin/vi*
    -r-xr-xr-t 1 bin bin 20748 Feb 18 2003 /opt/K/SCO/Unix/5.0.7Hw/bin/ls*
    -rwxr-xr-t 1 bin bin 59536 Feb 18 2003 /opt/K/SCO/Unix/5.0.7Hw/bin/sh*
    -rwxr-xr-t 1 bin bin 117232 Feb 18 2003 /opt/K/SCO/Unix/5.0.7Hw/sbin/sh*


    So I consulted the man page for chmod(C) in OSR5.0.7:

    "If the file is not a directory, the sticky bit has no
    effect. (If the sticky bit is set on an executable file,
    the system attempts to keep the text segment in core after
    execution ceases.)"


    In Debian 3.1 the chmod man page says:

    "STICKY FILES
    On older Unix systems, the sticky bit caused executable
    files to be hoarded in swap space. This feature is not
    useful on modern VM systems, and the Linux kernel ignores
    the sticky bit on files. Other kernels may use the sticky
    bit on files for system-defined purposes. On some systems,
    only the superuser can set the sticky bit on files."

    I must confess it is the first time I see the sticky bit set on
    executables on a live system (I just checked and there is none
    in my Debian system).

    The question I have is: does it really make a difference the
    sticky bit on executables in OSR5, or is it just a relic from
    past times?

    Regards,

    Pepe.

  2. Re: Why sticky bit on executables?

    Pepe wrote:

    > As I was in the process of changing the default shell from /bin/sh to
    > /bin/ksh in an OperServer 5.0.7 test machine, I noticed the /bin/sh
    > binary had the sticky bit set:


    > So I consulted the man page for chmod(C) in OSR5.0.7:
    >
    > "If the file is not a directory, the sticky bit has no
    > effect. (If the sticky bit is set on an executable file,
    > the system attempts to keep the text segment in core after
    > execution ceases.)"
    > only the superuser can set the sticky bit on files."
    >
    > I must confess it is the first time I see the sticky bit set on
    > executables on a live system (I just checked and there is none
    > in my Debian system).
    >
    > The question I have is: does it really make a difference the
    > sticky bit on executables in OSR5, or is it just a relic from
    > past times?


    Last time I investigated this question was many years and several
    releases ago, perhaps OSR5.0.2. At that time I worked at SCO and had
    full source access. As far as I can remember, the sticky bit in the
    inode was being carried into some other kernel structures, but I don't
    think I was able to find anything that actually paid attention to the
    resulting bits. If I remember right, it was ending up turning on a bit
    in the region table structures that sounded like it was supposed to keep
    around region headers (but not necessarily their contents). But I'm
    pretty sure the region code had stopped paying attention to it.

    Whatever the last vestiges were, it was stuff that you would have real
    difficulty measuring no matter what contrived benchmark you used.

    The bits are just a relic. Of course, you may experience some
    hysteresis if you try to turn them off. custom+ will whine about it and
    in some cases will "fix" it...

    >Bela<


  3. Re: Why sticky bit on executables?

    Thank your for your insight, Bela.

    Bela Lubkin wrote:

    > Whatever the last vestiges were, it was stuff that you would have real
    > difficulty measuring no matter what contrived benchmark you used.


    I was kind of hopping there was some algorithm in OSR5's version of the
    UNIX kernel which would give sticky'ed executables preference to reside
    in RAM as cached, against other non-sticky'ed executables, once they
    were run...

    It is not the case, then.

    It would be a nice idea anyway, I think...

    > The bits are just a relic. Of course, you may experience some
    > hysteresis if you try to turn them off. custom+ will whine about it
    > and in some cases will "fix" it...


    I am certainly not inclined to amend the system default permissions for
    "sh", "ls" and "vi". Specially as I chose the "High Security" install
    option. Also, I see there is the integrity(ADM) tool and I think it can
    be very useful, I wouldn't want to annoy it. :-)

    Regards,

    Pepe.

  4. Re: Why sticky bit on executables?

    In article , Pepe wrote:
    >Thank your for your insight, Bela.


    >Bela Lubkin wrote:


    > > Whatever the last vestiges were, it was stuff that you would
    > > have real difficulty measuring no matter what contrived
    > > benchmark you used.


    >I was kind of hopping there was some algorithm in OSR5's
    >version of the UNIX kernel which would give sticky'ed
    >executables preference to reside in RAM as cached, against other
    >non-sticky'ed executables, once they were run...


    >It is not the case, then.


    >It would be a nice idea anyway, I think...


    No need with the Virtual Memory we have today.

    Originally if there was not enough contiguous space in memory for a
    file, then items would be swapped out to enable the new program to
    load. With VM we can map what appears to the OS to be contiguous
    memory and not have to swap things out to get real contiguous
    memory. Setting the sticky bit would put the files with the bit
    set - eg the most used files such as sh, vi, and others, to reside
    in the swap system, where all files are stored contiguously, and
    would NOT be removed. Other files in the swap will be removed if
    more swap space was needed. Loading directly from swap was
    typically much faster.

    Now with demand-paged systems we only need to load the parts of the
    program we need, and when we get a page-fault the rest will be
    loaded.

    As I recall it was SysV.3 where the VM first came to prominance.

    Looking at my SysV.2 manual [full set that came with my Microport
    system back in about 1986 or so] the chmod page says:

    "... If an exceuteable files is prepared for sharing the mode bit
    01000 prevents the system from abandoning the swap-space image of
    the program-text portion of the file when it last user terminates.
    Thus, when the next user of the executes it, the text need not be
    read from the system, but can simply be swapped in saving time"

    However with the newer systems demand-paging only the portions
    needed are loaded into memory thus saving memory, reducing disk
    access time, and the paged in portions will be shared by other
    programs/users needing it unless someone modifies it then the
    copy-on-write is used so that the new user has his own space.

    > > The bits are just a relic. Of course, you may experience some
    > > hysteresis if you try to turn them off. custom+ will whine about it
    > > and in some cases will "fix" it...


    >I am certainly not inclined to amend the system default permissions for
    >"sh", "ls" and "vi". Specially as I chose the "High Security" install
    >option. Also, I see there is the integrity(ADM) tool and I think it can
    >be very useful, I wouldn't want to annoy it. :-)


    Your previous post indicated [as I recall] that only the super-user
    can set the sticky bit [on directories]. In other *n*x systems the
    user can set the sticky bit on their own directories.

    Be glad that we don't need/use the sticky bit for programs anymore.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  5. Re: Why sticky bit on executables?

    On Mon, Jul 09, 2007, Bill Vermillion wrote:
    >In article , Pepe wrote:
    >>Thank your for your insight, Bela.

    >
    >>Bela Lubkin wrote:

    >
    >> > Whatever the last vestiges were, it was stuff that you would
    >> > have real difficulty measuring no matter what contrived
    >> > benchmark you used.

    >
    >>I was kind of hopping there was some algorithm in OSR5's
    >>version of the UNIX kernel which would give sticky'ed
    >>executables preference to reside in RAM as cached, against other
    >>non-sticky'ed executables, once they were run...

    >
    >>It is not the case, then.

    >
    >>It would be a nice idea anyway, I think...

    >
    >No need with the Virtual Memory we have today.
    >
    >Originally if there was not enough contiguous space in memory for a
    >file, then items would be swapped out to enable the new program to
    >load. With VM we can map what appears to the OS to be contiguous
    >memory and not have to swap things out to get real contiguous
    >memory. Setting the sticky bit would put the files with the bit
    >set - eg the most used files such as sh, vi, and others, to reside
    >in the swap system, where all files are stored contiguously, and
    >would NOT be removed. Other files in the swap will be removed if
    >more swap space was needed. Loading directly from swap was
    >typically much faster.


    Back in the days of Xenix on Radio Shack Model 16/6000s, the
    sticky bit was useful for programs like ``vi'' as it would leave
    the text area in RAM for a reasonable amount of time after the
    last copy exited. For ``vi'' this was noticeable as it was
    common to start and stop it many times for different files, and
    it made a very noticeable difference in the start time.

    Of course those machine maxed at 512K RAM unless one used
    something like Bob Snapp's kludged memory boards which could
    expand it to a full meg.

    Bill
    --
    INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    ``Ah, you know the type. They like to blame it all on the Jews or the
    Blacks, 'cause if they couldn't, they'd have to wake up to the fact that
    life's one big, scary, glorious, complex and ultimately unfathomable
    crapshoot -- and the only reason THEY can't seem to keep up is they're a
    bunch of misfits and losers.''
    -- A analysis of Neo-Nazis, from "The Badger" comic

  6. Re: Why sticky bit on executables?

    On Jul 9, 8:15 am, b...@wjv.com (Bill Vermillion) wrote:
    > In article , Pepe wrote:
    > >Thank your for your insight, Bela.
    > >Bela Lubkin wrote:
    > > > Whatever the last vestiges were, it was stuff that you would
    > > > have real difficulty measuring no matter what contrived
    > > > benchmark you used.

    > >I was kind of hopping there was some algorithm in OSR5's
    > >version of the UNIX kernel which would give sticky'ed
    > >executables preference to reside in RAM as cached, against other
    > >non-sticky'ed executables, once they were run...
    > >It is not the case, then.
    > >It would be a nice idea anyway, I think...

    >
    > No need with the Virtual Memory we have today.
    >
    > Originally if there was not enough contiguous space in memory for a
    > file, then items would be swapped out to enable the new program to
    > load. With VM we can map what appears to the OS to be contiguous
    > memory and not have to swap things out to get real contiguous
    > memory. Setting the sticky bit would put the files with the bit
    > set - eg the most used files such as sh, vi, and others, to reside
    > in the swap system, where all files are stored contiguously, and
    > would NOT be removed. Other files in the swap will be removed if
    > more swap space was needed. Loading directly from swap was
    > typically much faster.
    >
    > Now with demand-paged systems we only need to load the parts of the
    > program we need, and when we get a page-fault the rest will be
    > loaded.
    >
    > As I recall it was SysV.3 where the VM first came to prominance.
    >
    > Looking at my SysV.2 manual [full set that came with my Microport
    > system back in about 1986 or so] the chmod page says:
    >
    > "... If an exceuteable files is prepared for sharing the mode bit
    > 01000 prevents the system from abandoning the swap-space image of
    > the program-text portion of the file when it last user terminates.
    > Thus, when the next user of the executes it, the text need not be
    > read from the system, but can simply be swapped in saving time"
    >
    > However with the newer systems demand-paging only the portions
    > needed are loaded into memory thus saving memory, reducing disk
    > access time, and the paged in portions will be shared by other
    > programs/users needing it unless someone modifies it then the
    > copy-on-write is used so that the new user has his own space.
    >
    > > > The bits are just a relic. Of course, you may experience some
    > > > hysteresis if you try to turn them off. custom+ will whine about it
    > > > and in some cases will "fix" it...

    > >I am certainly not inclined to amend the system default permissions for
    > >"sh", "ls" and "vi". Specially as I chose the "High Security" install
    > >option. Also, I see there is the integrity(ADM) tool and I think it can
    > >be very useful, I wouldn't want to annoy it. :-)

    >
    > Your previous post indicated [as I recall] that only the super-user
    > can set the sticky bit [on directories]. In other *n*x systems the
    > user can set the sticky bit on their own directories.
    >
    > Be glad that we don't need/use the sticky bit for programs anymore.
    >
    > Bill
    > --
    > Bill Vermillion - bv @ wjv . com


    In the Olde Days we used to set the sticky bit on programs we were
    about to demo. Made the app come up snappier. Probably a vestigial
    setting for these commonly used programs. Not much security impact.

    But hardware's changed and OS's have changed. Nowadays you run the
    demo a couple of times first to prime all the system caches. The more
    things change...

    --RLR


+ Reply to Thread