iraf-v216 · Code · Issues (50) · Pull requests (81)

iraf.net Issue #23

install script does unexpected and dangerous change of /tmp dir

closed olebole opened this issue on 2017-05-02 · 2 comments

---

olebole commented on 2017-05-02

The ./install script contains the following piece:

if (( "do_system"==1 )); then  
    # Allow deletion of files in /tmp - needed for multiuser tape allocation.  
    ECHO -n "Reset /tmp sticky bit setting ...                              "  
    if [ "$exec" == "yes" ]; then  
        chmod -t /tmp  
    fi  
    DO_OK  
fi  

This is a crude hack, removing a flag on the /tmp directory that ensures that people cannot delete or rename other people’s files from there which by purpose opens a number of security holes on multiuser systems – without any gain. Or who is still using “multiuser tape allocation” with IRAF?

---

olebole commented on 2017-09-05

# Allow deletion of files in /tmp - needed for multiuser tape allocation.  

I spend some time to find out where this multiuser tape allocation actually happens. The places in questions were alloc.c (or maybe zalloc.c); but they refer to devices in /dev only. And also, alloc.e is a setuid program that does not need the sticky bit.

There is an entry in the FAQ that is related, but it is for VMS, and I couldn’t find the creation of the mentioned file/directory. There is also an old question in the forum, but this is almost 20 years old.

So it is quite unclear why these lines are in the install script.

---

olebole commented on 2017-09-05

OK, I found the place: sys/mtio/mtio.h, which defines it as /tmp/mt?.lok. This violates the Linux Filesystem Hierarchy Standard; at least on Linux it should therefore go to /var/lock.

And since /var/lock/ also has the sticky bit set, the correct solution here would IMO be to create a world writable subdirectory there and to put the lock files into that. If there are still any tape users on IRAF left.

@iraf? What is your opinion on that?

---

Fixed in #24

---

Last updated on 2017-09-26