Re: view like 'tail -f'
Hello, On Tue, 16 Jan 2007, [EMAIL PROTECTED] wrote: Suggestion: modify the internal viewer so that it can act like 'tail -f'. Why do you think it is usefull to have this functionality ? What are its use cases ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello Lubomir, On Mon, 22 Jan 2007, Lubomir Grajciar wrote: When I try to copy file(s) with unchecked preserve atributes checkbox as regular user, copied files hasn't attributes based on my umask. My umask is: 0022 Copied file attributes: 600 When I try to create a new file (for example with shift-F4), it is created with right attributes (644). Thanks for noticing and reporting this! It is indeed a bug and it has been here for the last 5 years. For the curious - there is a thread with a subject of Problems with vfs / ftpfs started on 27 Feb 2002. As it can be seen the patch posted by Andrew calls chmod() on the target file only if preserve attributes is set. However, it has to be called in both cases since the destination file is created with mode 600 initially due to security concerns - more info can be found in file.c . I'll revert that patch. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hi, [...] As it can be seen the patch posted by Andrew calls chmod() on the target file only if preserve attributes is set. However, it has to be called in both cases since the destination file is created with mode 600 initially due to security concerns - more info can be found in file.c . I think this is overcomplicated... open() does not create the file with the permission taken from its third argument, it masks it with umask. So currently the file is not created with mode 600, but with mode (600 ^umask). What's wrong with the following simple solution? When creating the file, pass the permissions of the old file to the open() call. This way it will have no more permissions than the original file, and no more permission than umask suggests. When copying is finished, call chmod() only if preserve attributes is set. -- Egmont ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello Egmont,
On Thu, 22 Feb 2007, Egmont Koblinger wrote:
Hi,
[...] As it can be
seen the patch posted by Andrew calls chmod() on the target
file only if preserve attributes is set. However, it has to
be called in both cases since the destination file is created
with mode 600 initially due to security concerns - more info
can be found in file.c .
I think this is overcomplicated... open() does not create the file with the
permission taken from its third argument, it masks it with umask. So
currently the file is not created with mode 600, but with mode (600
^umask).
What's wrong with the following simple solution?
When creating the file, pass the permissions of the old file to the open()
call. This way it will have no more permissions than the original file, and
no more permission than umask suggests.
When copying is finished, call chmod() only if preserve attributes is set.
/* Create the new regular file with small permissions initially,
do not create a security hole. FIXME: You have security hole
here, btw. Imagine copying to /tmp and symlink attack :-( */
while ((dest_desc = mc_open (dst_path, O_WRONLY | (ctx-do_append ?
O_APPEND : (O_CREAT | O_TRUNC)), 0600)) 0) {
I remember that there is a discussion somewhere on the mailing list
as to what this security concern is. I will try to dig it and see
whether it really makes sense to do it the way it currently is.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
Re: maybe a bug in copy files
Hello, On Thu, 22 Feb 2007, Pavel Tsekov wrote: I remember that there is a discussion somewhere on the mailing list as to what this security concern is. I will try to dig it and see whether it really makes sense to do it the way it currently is. Here it is: http://mail.gnome.org/archives/mc-devel/2006-June/msg00063.html Shall we discuss how to create the file in a secure manner and avoid the call to mc_chmod() ? ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[PATCH] xnc.hlp converted to mandoc format
Hello, I converted binary xnc.hlp to mandoc format and merged it with mc.1.in. Here are the patches to src/man2hlp.c, doc/mc.1.in (English version), and doc/Makefile.am. You can do $ diff mc.hlp.old mc.hlp to see that nothing was broken by the patch... Of course, there are some minor differences in the output, but they occur *only* with preformatted text that was in xnc.hlp. Let me describe the patch to man2hlp: 1) New commands: .ti - Temporary indent .ce - Center lines .ex - Used to exclude from the man page the text from xnc.hlp .\BOOKMARK With the .\BOOKMARK command you can place a 'bookmark' inside the node, and reference it with a link (this is used in 'NO WARRANTY' link, I already posted about this on the maillist). 2) Small change in handling .TP label to be compatible with new .ti command. The old implementation assumed that the next input line following .TP command is a paragraph label. This assumption is wrong: the next line could be a comment or another troff's command. So I did a small change - I moved that code out of the main reading loop to a better place. This also allowed to simplify the logic a bit: 'tp_flag' was triple-state (0,1,2), now it has only two states (0,1). 3) Added support of troff commands in no-fill mode. When handling .nf (no-fill command) man2hlp used a simple solution: the input was copied to output verbatim, and troff commands were ignored in that mode. For example, for the following input: .nf .B Sample text the output was .B Sample text. My patch emulates no-fill mode more closely to groff: for the input shown above the output will be Sample text in bold font. mc.1.in now takes advantage of that feature. 4) New function - unescaperise(), to remove backslash-quoting. The old implementation did it by pasting the same piece of code in 4 various parts of the program. 5) Modified string_len() function: a) Added handling of TAB character: it is assumed 8 chars in length. b) Removed that mysterious code: /* Ugly hack to prevent loss of one space */ len++; I really don't understand what this 'ugly hack' is used for. I tried to find an answer in ChangeLogs and original version of man2hlp.c from mc-4.1.35... No success. Anyway, this code is never used because printing of node headers is done directly via fprintf(), and not via print_string(). Since it has never been actually used I decided to remove it to prevent confusion. Regards, Grigory mc-xnc_hlp_gone.patch.gz Description: application/gzip ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
