similar to: strip setuid/setgid bits on backup (was Re: small security-related rsync extension)

I think this is more a philosophical issue. Some people want all applications to be like windows. "Are you sure you want to delete this file" <YES> "really"<yes>"it might make something stop working<yes>"permission denied". Unix assumes you know what you're doing. If you don't, tough. There's no reason you can't make a

On Fri, 19 Jul 2002, Dan Stromberg wrote: > Many apologies. If we update on the nfs server, as we've intended all > along, we should have no .nfs* files. Well, here's one thing that could make them, even if they're being created only directly, not over NFS. I'm watching the directory you're syncing into. I open the file while it's still there. You delete it, and

If it's anything like the rooms I saw last year...some rooms have "wardrobes" meaning that you have a unit with a shelf, a "closet" cabinet type thing, and about 5 drawers. If you have lots of clothes, bring extra storage containers because thos drawers can't really hold much. Or don't bring so many clothes:) I think some of the two room doubles have huge-ass floor

> > This brings up an issue that I believe can be solved in a simpler way than > > with brute force C code. I suspect some of you will cringe when you hear > > this, but a taintperl log parsing program would be best for this. rsync > > could generate a verbose log file that is not human readable, designed to > > be read by a perl postprocessing script. I think this

Whoops, I apologize for the off topic e-nail. I meant to write a reply but I mixed up my messages to the various listservers I'm subscribed to. I'll remember to check my address next time. I've found a new way to run Rsync, it works pretty well, and involves a disk image mounted on a server that's created with Disk Copy. It serves our purpose pretty well for what we're doing

> > > never seen a file created with a newline in the filename > > (except, perhaps as a test). The newline in filename issue > > And in security exploits :-) Given a newline-based format, one *must* > quote or deny newlines in filenames, not assume they're rare. (No > obvious reason not to use URL-style %-quoting, or mime-style > =-quoting, if you want to

version: rsync v2.6.1 (+ a minor, unrelated patch). I'm rsyncing files (not as root) and am happy (indeed, for what I want, delighted) that the files at the target side end up owned by the account doing the rsync. However, I've found that if I have a setuid/setgid file on the source side, the target file ends up setuid/setgid too (but under a different id!). This happens whether

Hi OpenSSH developers, I'm using OpenSSH on a daily basis and I'm very pleased with the work you've done. I am contributing to some Open Source software hosted at Savannah https://savannah.nongnu.org/projects/tsp and we recently hit some sftp unexpected behavior: https://savannah.gnu.org/support/?105838 when using chmod sftp client command it appears that setuid / setgid bits are

https://bugzilla.mindrot.org/show_bug.cgi?id=1310 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org Blocks| |1452 --- Comment #3 from Damien Miller

https://bugzilla.mindrot.org/show_bug.cgi?id=1893 Summary: change ssh-keisign to setgid from setuid Product: Portable OpenSSH Version: 5.8p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: unassigned-bugs at mindrot.org

Hello! Please, help! I have trouble with Dovecot's Deliver utility. I don't know how to avoid errors. Let me know what additional related information do you need? 1) Its call in Exim's configure: ========================================== local_delivery_spam_transport: driver = pipe command = /usr/local/libexec/dovecot/deliver -c

Package: logcheck-database Version: 1.2.33 Severity: normal I just installed 1.2.33, and it made my rules dirs setuid, not setgid... - Marc -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-k7 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of

https://bugzilla.samba.org/show_bug.cgi?id=13239 Bug ID: 13239 Summary: "rsync --times" does not keep dirs' setgid bits when user not member of setgid group Product: rsync Version: 3.1.2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5

Hi everyone, I am pretty new to R, so be patient. I am trying to intersect 2 columns and in the rows that intersect, I want information from the 3rd column to be brought with it. I think it will be easier to explain with an example example.csv <http://r.789695.n4.nabble.com/file/n4675136/example.csv> . In my example, I have a reference list of fruit (first column), and my fruit of

http://bugzilla.mindrot.org/show_bug.cgi?id=136 Summary: setgid() deemed to fail for non-suid ssh client on linux if using other than primary group Product: Portable OpenSSH Version: 3.0.2p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh

Somewhere between Samba 4.2.10 and 4.6.2 (came with CentOS 7 updates) the setgid bit is not inherited anymore when making directories via my Samba service. Everything else is still fine. With ssh direct on the file system or sftp, i get all permissions and acls inherited nicely. Also with Samba all acls are still just fine, except that setgid bit is not inherited (s on the group executable

When copying locally as well as remotely inside a setgid dir, the option --times has the unwanted side effect of making the newly created directories not have the setgid bit set, but only when the user running rsync is not a member of the corresponding group. The extra option --omit-dir-times prevents the loss of the setgid bit in this case. Is this a bug as I think it is? Note that files

Hello all, I'm trying to get the expire plugin working, but still having issues even with 1.1RC5. If I run the expire tool I get the following error: server:~# dovecot --exec-mail ext /usr/local/libexec/dovecot/expire-tool Fatal: setgid(100) failed with euid=2005, gid=0, egid=0: Operation not permitted Same thing with --test: server:~# dovecot --exec-mail ext

Hi Lorenzo and Dale, My setup is like Lorenzo's completely based on setgid being propagated. The filesystem should determine the group used starting at a certain directory. Different "root" directories have different groups, and security is based on groups, not users. I tried all sorts of settings combinations, alseo "force directory mode = 2770", but none propagates

Sorry if this is a nubbie question, but I?m getting: lda(jlbrown at bordo.com.au)<4444><QFg5KRHVBBxcEQAAYBwt+A>: Fatal: setgid(102 from userdb lookup) failed with euid=501(jlbrown), gid=20(staff), egid=20(staff): Operation not permitted (This binary should probably be called with process group set to 102 instead of 20(staff)) How can I fix this? (macOS Mojave, Dovecot 2.3.4)