similar to: Towards a solution of tmp-file problems.

Hi everyone, Thanks all for your feedback. Here is a reply to most of your comments.... Roger. Chris Evans wrote: > On Mon, 9 Mar 1998, Rogier Wolff wrote: > > not to give those rights away. A non-setuid program should not have to > > worry about buffer overruns (you can crash the program, wow!). It > Just a reminder, that in some cases, it _should_ worry. As a

Forwarding a message from Rogier Wolff: > > Nick Andrew wrote: > > Theo De Raadt pointed out (possibly not in this thread) that basing > > protection on euid is not workable. Although I like the concept of > > variable expansion in pathnames, I don''t see it as a security mechanism. > > Why not? Because programs that _were_ privileged but have set euid ==

I seem to have stumbled across another vulnerability in DIP. It appears to allow any user to gain control of arbitrary devices in /dev. For instance, I have successfully stolen keystrokes from a root login as follows... (I could also dump characters to the root console) $ whoami cesaro $ cat < /dev/tty1 <------ root login here bash: /dev/tty1: Permission denied

G''day Roger, Forwarding a message from wolff@BitWizard.nl: > Passing by fd means coding changes. > > The C compiler classically compiles you C program to preprocessed C > code in /tmp/ccxxxxx.i, throws that at the first compiler pass, ends > up with /tmp/ccxxxxx.s, throws the assembler at that file, gets > /tmp/ccxxxxxx.o and finally throws a linker at that file to

Forwarding a message from Steve \"Stevers!\" Coile: > This is already possible. Create the file then unlink it. The file > contents aren''t deleted and i-node isn''t released until the file is > closed. Without kernel support, unlinking the file at creation time requires a code change in the process which creates the file. And this doesn''t protect

> >For example (and this is only an example), a private namespace may be >assigned for each user at login time (at the level of the login shell). >Thus, the user''s "ls" commands see files in whatever directory the >private namespace is rooted, and for all intents and purposes it appears >to be an ordinary filesystem. Yet no other users can see this. User runs

Hi, I get my Email from my own SMTP server on the internet using "fetchmail". Some time ago I did the smart thing and configured dovecot to use SSL and the letsencrypt certificate that automatically renews. Welllll..... a few days ago my certificate expired and the fetchmail deamon running in the background had nowhere to complain. So I didn't notice. It turns out that dovecot

>Forwarding a message from Steve \"Stevers!\" Coile: >> This is already possible. Create the file then unlink it. The file >> contents aren''t deleted and i-node isn''t released until the file is >> closed. > >Without kernel support, unlinking the file at creation time requires >a code change in the process which creates the file. And this

Months ago there was a thread here about the implementation of a simple undelete-function (i.e: dont delete files, but move them to a folder). Is this this still a relevant idea or has this feature low priority ? thanx, peter ps: anyone knows about a 3rd-party software (propably on nt-side) that implements such a feature ? -- mag. peter pilsl phone: +43 676 3574035 fax : +43 676 3546512

I would be surprised if someone hasn''t encountered this already, but I haven''t found any discussion of the nature of this problem. I run RehHat 5.0. If a user makes a mistake in the login process such as the following: login: mistake password: xxx Login incorrect! login: username password xxxx bash$ a ps will show, among other things, 2333 /bin/login --mistake. Since

Hi, I am trying to get sieve working on a new OpenSuse leap 42.2 install. On my 'old' OpenSuse 13.2 machine it worked fine. The problem is that Managesieve can't access the script store and won't let me create any script. It says permission denied on ~/sieve directory. See log below. I 've activated debug logging, but that doesn't give any clues to me. Also, I've

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Buffer overflow in cron daemon Advisory ID: RHSA-1999:030-01 Issue date: 1999-08-25 Updated on: Keywords: vixie-cron crond MAILTO Cross references: --------------------------------------------------------------------- 1. Topic: A buffer overflow exists in crond, the cron

I think this is an issue of serious interest to many of the subscribers of these lists; it would effectively ban a lot of security-related tools that many of use now find indispensable, e.g. ssh, pgp. ------- Start of forwarded message ------- Date: 21 Mar 1997 10:11:57 GMT From: rja14@cl.cam.ac.uk (Ross Anderson) Approved: R.E.Wolff@BitWizard.nl Subject: DTI proposals on key escrow The British

Hi Stephan, > Normally, Dovecot permission errors are more helpful than that. So, > this > error message in itself is a bit of a bug: I'm glad to h've been able to help with this beta-test ;-) > About the cause of this error: keep in mind that the whole directory > path needs read/execute permission, not only the leaf directory. Have checked. They are... > You

Hi, Recently once again an exploit for SuperProbe was posted to the bugtraq. That message was forwarded to linux-security and Rogier Wolff rejected it on the basis of the author of the SuperProbe (David Wexelblatt) comment that it was never intended to be suid. In general, there is absolutely no reason for programs that are supposed to be run only by root to be suid to root! If your

On 09/10/2020 11:50, Plutocrat wrote: > On 09/10/2020 4:16 pm, Rogier Wolff wrote: >> It turns out that dovecot had been running uninterrupted since august >> 13th, the certificate was renewed on september 7th and I suspect it >> expired on october 7th. > I guess you could do a few things yourself to make sure the cert is valid. Thinking out loud: > > - Blunt

--------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Denial of service attack in in.telnetd Advisory ID: RHSA-1999:029-01 Issue date: 1999-08-19 Updated on: Keywords: telnet telnetd Cross references: --------------------------------------------------------------------- 1. Topic: A denial of service attack has been fixed in

Oops. Missed one line in the last patch.... Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * The Worlds Ecosystem is a stable system. Stable systems may experience * * excursions from the stable situation. We are currently in such an * * excursion: The stable situation does

-----BEGIN PGP SIGNED MESSAGE----- Hi everyone - Someone I''m working with has a requirement to map ethernet card addresses to unique IP addresses, and then have a Linux IP masquerade server know of this mapping list and not allow any data to pass from any ethernet card that a) it doesn''t know about, or b) isn''t assigned the right IP. Ideally it would also log this

Hi, There have been several replies on the syslogd question. All 2 to 4 lines long. I therefore gathered them here. Roger. ----------------------------------------------------------------- From: Paul Kenyon <pkenyon@loctech.com> Date: Wed, 24 Jun 1998 11:37:01 -0500 I believe it is possible to pipe anything through SSH. I''ll find the URL to the info and post it. I