walt wrote:
type="strlist">noexec <=== look
And there are more options suitable for fat filesystems, which
is the default for usb sticks.
I noticed later it also has 'exec' in my system which seemed
contradictory, oh well, a lot to poke at later...
You are r
Paul Crawford wrote:
walt wrote:
Anyway, you probably want to look into how to configure the hald
system, which you can do using the command-line utilities packaged
with hal. You probably already have hal installed, so just try
typing hal-device at a command prompt and see what happens.
A qu
walt wrote:
I assume you are using some sort of automounting, or you would
just do the mounting yourself, right?
I was thinking here of the auto-mount on device plug-in. For the Windows
NTFS volumes I already have edited /etc/fstab to add the 'noexec' option.
As for the problem with Pan save
Paul Crawford wrote:
One thing that bothers me is the way LINUX seems to default to
execute-enabled on such drives (most likely USB sticks). OK, you might
want to run stuff off a CD for installing, but given the ease of viruses
in the world of Windows to propagate using either autorun or user
gu
Steven D'Aprano wrote:
Windows doesn't understand Unix/Linux file systems, so it can't see Unix
permissions natively. However, Windows does support NTFS, which uses an
extraordinarily rich set of Access Control Lists capable of emulating
anything Unix permissions can do, and far, far more. Most
Duncan wrote:
But, your mention of SAMBA jarred my thinking. If I'm not mistaken (and
maybe I am as I've never used SAMBA), Windows won't see Unix file
permissions no matter what serves up the file. It's just not designed to
work that way.
Windows doesn't understand Unix/Linux file systems
walt posted
gnq4up$fi...@ger.gmane.org, excerpted below, on Sun, 22 Feb 2009 00:06:50
+:
> On Thu, 19 Feb 2009 23:35:32 +, Duncan wrote:
>
>> The thing is, however, that UUE includes the file permission field, and
>> even Windows apps will need to put /something/ there. My question
>>
On Thu, 19 Feb 2009 23:35:32 +, Duncan wrote:
> The thing is, however, that UUE includes the file permission field, and
> even Windows apps will need to put /something/ there. My question would
> be what gravity puts there, and where it gets it (some config option, a
> default, asks each time
Duncan wrote:
--- pan/tasks/decoder.cc.orig 2009-02-20 08:28:14.0 -0800 +++
pan/tasks/decoder.cc2009-02-20 08:31:54.0 -0800 @@
-135,6 +135,7 @@
{
UUSetMsgCallback (this, uu_log);
UUSetOption (UUOPT_DESPERATE, 1, NULL); // keep incompletes;
they'
walt posted
gnmmhs$k0...@ger.gmane.org, excerpted below, on Fri, 20 Feb 2009 16:42:37
+:
> Now that I understand the proposed patch above I agree that it's better
> than the one I came up with, but I think it's cleaner to put it here:
>
> --- pan/tasks/decoder.cc.orig 2009-02-20 08:28:14.
On Fri, 20 Feb 2009 11:55:51 +, Paul Crawford (at UoD) wrote:
> Duncan wrote:
>> That said, internal or not, keeping the library code as pristine as
>> possible should be a goal, so I'd say option 1, adding the call to
>> UUSetOption (UUOPT_IGNMODE, 1 NULL) somewhere, is the "correct"
>> solut
Duncan wrote:
That said, internal or not, keeping the library code as pristine as
possible should be a goal, so I'd say option 1, adding the call to
UUSetOption (UUOPT_IGNMODE, 1 NULL) somewhere, is the "correct" solution.
I managed to compile pan-0.133 on my Fedora box and confirmed that, as
walt posted
gnjtgd$se...@ger.gmane.org, excerpted below, on Thu, 19 Feb 2009 15:22:53
+:
> I just looked at Gravity source code and it's obviously still a true
> Windows application. Far more likely than either hypothesis is that the
> perp simply forged his headers to cast suspicion on som
On Thu, 19 Feb 2009 14:06:46 +, Duncan wrote:
> walt posted
> gnjm9r$uj...@ger.gmane.org, excerpted below, on Thu, 19 Feb 2009
> 13:19:55 +:
>
>> Interesting to note that only attachments posted from a *nix news
>> client would cause this problem in the first place, and the article in
>
On Thu 19 Feb 2009 at 11:37:39 +, Duncan wrote:
> That said, internal or not, keeping the library code as pristine as
> possible should be a goal, so I'd say option 1, adding the call to
> UUSetOption (UUOPT_IGNMODE, 1 NULL) somewhere, is the "correct" solution.
I agree, for the following ad
walt posted
gnjm9r$uj...@ger.gmane.org, excerpted below, on Thu, 19 Feb 2009 13:19:55
+:
> Interesting to note that only attachments posted from a *nix news client
> would cause this problem in the first place, and the article in question
> was posted with Gravity, which was once a Windows-o
Steven D'Aprano posted
499d442f.8020...@pearwood.info, excerpted below, on Thu, 19 Feb 2009
22:36:15 +1100:
> Now that Duncan has tracked down the cause of the bug -- well-done
> Duncan, fantastic work
To be fair, it wasn't all me. I played a part, certainly, but it has
been a community effor
On Thu, 19 Feb 2009 22:36:15 +1100, Steven D'Aprano wrote:
> Paul Crawford wrote:
>> walt wrote:
>>> I don't know what you and I are doing differently, but I just saved
>>> that same
>>> attachment and got 644, as I would expect. Are you saving to a FAT
>>> filesystem,
>>> maybe?
>>
>> I don't k
Paul Crawford posted
499d2152.4030...@sat.dundee.ac.uk, excerpted below, on Thu, 19 Feb 2009
09:07:30 +:
> I thought about the possible changes to fix this, and it occured that
> there are two options:
>
> (1) Add the call to UUSetOption (UUOPT_IGNMODE, 1, NULL) somewhere.
>
> (2) Change l
Paul Crawford wrote:
walt wrote:
I don't know what you and I are doing differently, but I just saved
that same
attachment and got 644, as I would expect. Are you saving to a FAT
filesystem,
maybe?
I don't know what Steven D'Aprano used.
Fedora, probably 7 or 8, I forget which (that PC is
Paul Crawford posted
499d2eae.7030...@sat.dundee.ac.uk, excerpted below, on Thu, 19 Feb 2009
10:04:30 +:
> I have just confirmed that Fedoara (and by implication Red Hat) with Pan
> 0.133 has the same behaviour so a concern also for 'enterprise' LINUX
> users.
... Except pan isn't the type
Duncan wrote:
I'm thinking about it as a security bug as well, but at this point if it
were just me, I'd talk it over with the Gentoo maintainer and get their
opinion before I filed it as such with GNOME and CERT or whatever. What
do others here think?
Of course I think it is a serious hole
walt wrote:
I don't know what you and I are doing differently, but I just saved that same
attachment and got 644, as I would expect. Are you saving to a FAT filesystem,
maybe?
I don't know what Steven D'Aprano used.
I found the 755 on my Ubuntu 8.10 box using ext3 with Ubuntu's package
manag
Duncan wrote:
I'm beginning to think so, but decided to sleep on it this morning. So I
did, and I still think so. However, we're close enough to a patch that
testing one and having it ready to go (if we're right) will be useful.
I thought about the possible changes to fix this, and it occure
"Paul Crawford (at UoD)"
posted 499c48bd.3010...@sat.dundee.ac.uk, excerpted below, on Wed, 18 Feb
2009 17:43:25 +:
> Should this be entered as a 'bug report' for Pan? What is the best route
> to getting it resolved in a manner that is pushed out to the bulk of
> ordinary users soon?
I'm be
On Tue, 17 Feb 2009 11:10:00 +1100, Steven D'Aprano wrote:
> On Tue, 17 Feb 2009 07:30:55 am Paul Crawford wrote:
>> I just tried saving a suspect file of the avi.exe sort to see how it
>> behaved under LINUX using Pan 0.132 and I found it used '755'
>> permission settings thus rendering it (theor
Dear Duncan,
I found that in the my search as well, but I lost the trail trying to
find where and whether pan used that library in that way, or whether it
used something else (like the gmime uue and yenc functionality, which I
found as well, it likely didn't have yenc tho back when Charles star
"Paul Crawford (at UoD)"
posted 499afa13.3030...@sat.dundee.ac.uk, excerpted below, on Tue, 17 Feb
2009 17:55:31 +:
> Dear Duncan,
>> FWIW, I just changed my pan starter script to set the umask to 0137
>> before it starts pan, and test-saved that same attachment after
>> reinvoking pan with
Rinaldi J. Montessi wrote:
dev-libs/gmime-2.2.23 (/usr/lib64/libgmime-2.0.so.2 -> ...)
I'm guessing that's what's responsible, as a library, but as I said,
there's no pan code dealing with permissions -- it's all the library.
Not necessarily, but it has nothing to do with d/l perms:
/usr/l
Duncan wrote:
> equery b libgmime-2.0.so.2
> [ Searching for file(s) libgmime-2.0.so.2 in *... ]
> dev-libs/gmime-2.2.23 (/usr/lib64/libgmime-2.0.so.2 -> ...)
>
> I'm guessing that's what's responsible, as a library, but as I said,
> there's no pan code dealing with permissions -- it's all the li
Steven D'Aprano posted
499aba3d.8040...@pearwood.info, excerpted below, on Wed, 18 Feb 2009
00:23:09 +1100:
> Overheard in the boardroom of Ford Motor Company:
>
> "Oh no, you can't blame our SUVs for their poor fuel economy or for
> producing vast amounts of carbon dioxide, carbon monoxide, ni
Dear Duncan,
After finding the group and then the thread, then confirming the right
post, I downloaded (to cache, my default download action) it, then when
it was all in cache, hit save, and selected save both text and
attachments, since I wanted to investigate what on the raw message
contains
Duncan wrote:
So it doesn't look like I'm going to be made to eat some of those 250
lines now after all, tho only by virtue of the fact that it's not the pan
code that's doing it but the library. =:^)
Overheard in the boardroom of Ford Motor Company:
"Oh no, you can't blame our SUVs for the
Paul Crawford posted
499a9626.80...@sat.dundee.ac.uk, excerpted below, on Tue, 17 Feb 2009
10:49:10 +:
> Dear Duncan,
>> The above claim, that under Linux, files are created with default
>> permission 644, is simply not accurate. It's too general (perhaps
>> certain distributions, not "Linu
Dear Duncan,
The above claim, that under Linux, files are created with default
permission 644, is simply not accurate. It's too general (perhaps
certain distributions, not "Linux") and lacks a description of the vital
role umask plays in determining default file permissions.
I have just trie
Steven D'Aprano posted
200902171110.00439.st...@pearwood.info, excerpted below, on Tue, 17 Feb
2009 11:10:00 +1100:
> On Tue, 17 Feb 2009 07:30:55 am Paul Crawford wrote:
>> I just tried saving a suspect file of the avi.exe sort to see how it
>> behaved under LINUX using Pan 0.132 and I found it
36 matches
Mail list logo
