Mode bits set on inbound files by linux binkd

[Wilfred van Velzen]

Hi,

I noticed the files received in my inbound have the 'execute' bit set, which is
rather strange on linux/unix systems for regular files.

I think this is due to line 450 in inbound.c:

if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT, 0755)) ==
-1)

Where the mode bits are set to the hardcoded value: 0755. So there are no
differences between any OS's made.

Why is it done this way?

Bye, Wilfred.

[Markus Reschke]

Hello Wilfred!

Jan 04 23:00 2014, Wilfred van Velzen wrote to Developers:

WvV> I think this is due to line 450 in inbound.c:

WvV> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
WvV> 0755)) == -1)

WvV> Where the mode bits are set to the hardcoded value: 0755. So there
WvV> are no differences between any OS's made.

Which version of binkd do you got? I haven't found that issue in 1.02.

Regards,
Markus

[Wilfred van Velzen]

Hi,

On 2014-01-05 00:01:32, Markus Reschke wrote to Wilfred van Velzen:
about: "Mode bits set on inbound files by linux binkd":

WvV>> I think this is due to line 450 in inbound.c:

WvV>> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
WvV>> 0755)) == -1)

WvV>> Where the mode bits are set to the hardcoded value: 0755. So there
WvV>> are no differences between any OS's made.

MR> Which version of binkd do you got? I haven't found that issue in 1.02.

# ./binkd -v
Binkd 1.1a-28 (Oct 11 2013 15:53:57/Linux)


Bye, Wilfred.

[Markus Reschke]

Hello Wilfred!

Jan 05 01:15 2014, Wilfred van Velzen wrote to Markus Reschke:

WvV> # ./binkd -v
WvV> Binkd 1.1a-28 (Oct 11 2013 15:53:57/Linux)

I'm using the source code from ftp://happy.kiev.ua/pub/fidosoft/mailer/binkd/.
Is 1.1a-28 an alpha version or a fork?

Regards,
Markus

[Wilfred van Velzen]

Hi,

On 2014-01-05 13:01:08, Markus Reschke wrote to Wilfred van Velzen:
about: "Re: Mode bits set on inbound files by linux binkd":

WvV>> # ./binkd -v
WvV>> Binkd 1.1a-28 (Oct 11 2013 15:53:57/Linux)

MR> I'm using the source code from
MR> ftp://happy.kiev.ua/pub/fidosoft/mailer/binkd/. Is 1.1a-28 an alpha
MR> version or a fork?

Last october I used cvs to get the latest source from the same source:

cvs -d :pserver:***@cvs.happy.kiev.ua:/cvs co binkd

As suggested by the faq posted here, to get the latest sources from the current
branch.


Bye, Wilfred.

[Markus Reschke]

Hello Wilfred!

Jan 05 13:45 2014, Wilfred van Velzen wrote to Markus Reschke:

WvV> Last october I used cvs to get the latest source from the same
WvV> source:

WvV> cvs -d :pserver:***@cvs.happy.kiev.ua:/cvs co binkd

I see, 1.1a is the current version under development.

In 1.0.2:
fopen_again:
if ((f = fopen (buf, "ab")) == 0)
{
Log (1, "%s: %s", buf, strerror (errno));
return 0;
}
fseek (f, 0, SEEK_END); /* Work-around MSVC bug */


In 1.1a-??:
fopen_again:
if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT, 0755)) ==
-1)
{
Log (1, "%s: %s", buf, strerror (errno));
return 0;
}
if ((f = fdopen (fd, "ab")) == 0)
{
Log (1, "%s: %s", buf, strerror (errno));
return 0;
}
fseek (f, 0, SEEK_END); /* Work-around MSVC bug */


The fopen was replaced by open & fdopen, maybe to get more control of the files
modes?

Regards,
Markus

[Wilfred van Velzen]

Hi,

On 2014-01-05 14:20:32, Markus Reschke wrote to Wilfred van Velzen:
about: "Re: Mode bits set on inbound files by linux binkd":

WvV>> Last october I used cvs to get the latest source from the same
WvV>> source:

WvV>> cvs -d :pserver:***@cvs.happy.kiev.ua:/cvs co binkd

MR> I see, 1.1a is the current version under development.

MR> In 1.0.2:
MR> fopen_again:
MR> if ((f = fopen (buf, "ab")) == 0)
MR> {
MR> Log (1, "%s: %s", buf, strerror (errno));
MR> return 0;
MR> }
MR> fseek (f, 0, SEEK_END); /* Work-around MSVC bug */


MR> In 1.1a-??:
MR> fopen_again:
MR> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
MR> 0755))
MR> == -1) {
MR> Log (1, "%s: %s", buf, strerror (errno));
MR> return 0;
MR> }
MR> if ((f = fdopen (fd, "ab")) == 0)
MR> {
MR> Log (1, "%s: %s", buf, strerror (errno));
MR> return 0;
MR> }
MR> fseek (f, 0, SEEK_END); /* Work-around MSVC bug */

MR> The fopen was replaced by open & fdopen, maybe to get more control of
MR> the files modes?

Ok, this explains why it's happening, but not why it was changed to work in
this way. It would be interesting to find out! Who is currently doing the
developing of binkd? And why hasn't he responded here yet? ;)

You probably should be able to get some of this information from cvs, but I
hardly know anything about it...

Bye, Wilfred.

[Wilfred van Velzen]

Hi Markus,

On 2014-01-05 16:58:23, I wrote to you:

MR>> The fopen was replaced by open & fdopen, maybe to get more control of
MR>> the files modes?

WvV> Ok, this explains why it's happening, but not why it was changed to work
WvV> in
WvV> this way. It would be interesting to find out! Who is currently doing the
WvV> developing of binkd? And why hasn't he responded here yet? ;)

WvV> You probably should be able to get some of this information from cvs, but
WvV> I
WvV> hardly know anything about it...

Checking in cvs history showed that this code first appeared in this version of
inbound.c:

* Revision 2.46 2013/01/24 17:25:35 gul
* Support "-pipe" option on Win32

I'll ask Pavel to comment in here...

Bye, Wilfred.

[Pavel Gulchouck]

Hi Wilfred!

04 Jan 14, Wilfred van Velzen ==> Developers:

WvV> I noticed the files received in my inbound have the 'execute' bit set,
WvV> which is rather strange on linux/unix systems for
WvV> regular files.

WvV> I think this is due to line 450 in inbound.c:

WvV> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
WvV> 0755)) == -1)

WvV> Where the mode bits are set to the hardcoded value: 0755. So there are no
WvV> differences between any OS's made.

WvV> Why is it done this way?

It looks like my mistake.
I changed 0755 to 0666. Update binkd and apply umask for get proper mode on
unix.

Thanks for the report.

Lucky carrier,
Pavel
aka ***@gul.kiev.ua

[Wilfred van Velzen]

Hi Pavel,

On 2014-01-06 15:56:22, you wrote to me:

WvV>> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
WvV>> 0755)) == -1)

WvV>> Where the mode bits are set to the hardcoded value: 0755. So there
WvV>> are no differences between any OS's made.

WvV>> Why is it done this way?

PG> It looks like my mistake.
PG> I changed 0755 to 0666. Update binkd and apply umask for get proper mode
PG> on
PG> unix.

PG> Thanks for the report.

Thank you for the fix, and your work on the project! ;)

Bye, Wilfred.

[Benny Pedersen]

Hello Pavel!

06 Jan 2014 15:56, Pavel Gulchouck wrote to Wilfred van Velzen:

PG> It looks like my mistake.
PG> I changed 0755 to 0666. Update binkd and apply umask for get proper
PG> mode on unix.

0666 is a better one, but still a mistake, use 0600

sysops that need 07xx or 0x66 for get it working needs security coursce :)

also remember linux uses default parrent permissions


Regards Benny

... there can only be one way of life, and it works :)

[Pavel Gulchouck]

Hi Benny!

23 Jan 14, Benny Pedersen ==> Pavel Gulchouck:

BP> 06 Jan 2014 15:56, Pavel Gulchouck wrote to Wilfred van Velzen:

PG>> It looks like my mistake.
PG>> I changed 0755 to 0666. Update binkd and apply umask for get proper
PG>> mode on unix.

BP> 0666 is a better one, but still a mistake, use 0600

I think hardcoded 0666 is right. Then actual needed permissions can be get by
umask.
If 0600 is correct for your system, use umask 077.

BP> sysops that need 07xx or 0x66 for get it working needs security coursce :)

I agree for most cases, but not for all.
In theory, received files can be processed by different tools runned by
differend uids.
If you have (virtual) server for fidonet only, it's good enough to have
separate uids for mailer and tosser, and in this case files received by mailer
should be accessible by tosser.

Received files permission should be configurable and 0664 or 0644 by default,
as it is now (default umask is 002 or 022 in different systems).

BP> also remember linux uses default parrent permissions

Lucky carrier,
Pavel
aka ***@gul.kiev.ua

[Spiro Harvey]

PG> I think hardcoded 0666 is right. Then actual needed permissions can be

0666? That gives everyone who has access to the computer/file system write
access to the file. Perhaps you mean 0644?

0666 would mean:

owning user = read/write
owner's group = read/write
everyone else = read/write

0640 might be even better for a default non-executable file. But respecting
the user's default umask would be optimal.

[Wilfred van Velzen]

Hi Benny,

On 23 Jan 14 23:12, Benny Pedersen wrote to Pavel Gulchouck:
about: "Mode bits set on inbound files by linux binkd":

PG>> It looks like my mistake. I changed 0755 to 0666. Update binkd and
PG>> apply umask for get proper mode on unix.

BP> 0666 is a better one, but still a mistake, use 0600

As Pavel already remarked, if you want that you could set the umask for the
user that runs binkd to 0077. Mine is set to 0027, so files created by binkd
have 0640 as mode on my system. So I think 0666 is good in binkd, the rest is
up to the sysop.

Wilfred.

[Benny Pedersen]

Hello Wilfred!

04 Jan 2014 23:00, Wilfred van Velzen wrote to Developers:

WvV> I noticed the files received in my inbound have the 'execute' bit
WvV> set, which is rather strange on linux/unix systems for regular files.

WvV> I think this is due to line 450 in inbound.c:

WvV> if ((fd = open (buf, O_CREAT|O_APPEND|O_RDWR|O_BINARY|O_NOINHERIT,
WvV> 0755)) == -1)

WvV> Where the mode bits are set to the hardcoded value: 0755. So there
WvV> are no differences between any OS's made.

it should really be 0600 unless some remote like to eXecute a zip file

WvV> Why is it done this way?

+1


Regards Benny

... there can only be one way of life, and it works :)