search for: finegrained

1/ Most correctly configured unix servers are fairly secure. Workstations on the other hand are extremely easy to compromise. Even if the eeprom (on a sparc) is password protected the fact that a hacker can get physical access to the machine means that it's very likely to be compromised, but thats just life. (I'm sure at least some readers on this list will at some time in there life have

...rprised this wasn't supported alongside FWD_PERMIT_ANY_PORT. It's a simple enough change. I wonder if there was any debate on this or if it just slipped through the cracks as an uncommon use case? Note that this doesn't go down the more complex road of allowing more finegrained cases. The '*' is NOT actually a pattern, it is a symbol that means any host. Using *.bah.org will not work and is not intended to work. -- You are receiving this mail because: You are watching the assignee of the bug.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I''ve created a small patch, below, to take care of the case when you wish to use yum to ensure that the latest version of the package is installed but the yum server is down. This patch makes the assumption that, in the case of an yum query error, you want to assume that, if the application is installed, it is the latest. This allows you

So I'm just not ever going to pick up this patch; I spend a week trying to reverse engineer this; I posted a 7 patch series creating the equivalent, but in a gradual and readable fashion: http://lkml.kernel.org/r/20140310154236.038181843 at infradead.org You keep on ignoring that; I'll keep on ignoring your patches. I might at some point rewrite some of your pv stuff on top to get

So I'm just not ever going to pick up this patch; I spend a week trying to reverse engineer this; I posted a 7 patch series creating the equivalent, but in a gradual and readable fashion: http://lkml.kernel.org/r/20140310154236.038181843 at infradead.org You keep on ignoring that; I'll keep on ignoring your patches. I might at some point rewrite some of your pv stuff on top to get

Hi, Let me try to re-formulate, please tell me if I'm wrong. You have a bunch of users declared locally in /etc/passwd or something like that on one system. Now you would like to have another system using this users list with Samba. You also want these users to be valid only as long as the share exist. You don't want these users to be able to connect on system(s). If I'm right,

...I don't want to become a frog. How can I have write access locally? The only thing I know what to do is using setfacl, but the server resists that. Besides, it would have no bearing on the local system unless they were posix acl lists that were transmitted back. On the server I can create finegrained permissions but they are not transmitted ... actually they are, based on my logged in user. If my user on the server is part of group "backup" and I set permissions for backup: synoacltool -add hoho group:backup:allow:rwx:fd-- Then even though the group owner for file "hoho&quot...

On Thursday 12 July 2007 07:23, Torvald Riegel wrote: > > The single instruction constraints can, at their most flexible, constrain > > any set of possible pairings of loads from memory and stores to memory > > I'm not sure about this, but can we get issues due to "special" kinds of > data transfers (such as vector stuff, DMA, ...?). Memcpy implementations >

...> How can I have write access locally? > > The only thing I know what to do is using setfacl, but the server resists > that. > > Besides, it would have no bearing on the local system unless they were > posix acl lists that were transmitted back. On the server I can create > finegrained permissions but they are not transmitted ... actually they are, > based on my logged in user. > > If my user on the server is part of group "backup" and I set permissions > for backup: > > synoacltool -add hoho group:backup:allow:rwx:fd-- > > Then even though the g...

.../arch/x86/Kconfig.debug index 71c92db47c41..814353667075 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -156,7 +156,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86/x86_64/boot-options.rst for more + options. See Documentation/arch/x86/x86_64/boot-options.rst for more details. config IOMMU_LEAK diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 2c11c0f45d49..5ec825c863a6...

Hello all. Probably this question has already been posed in the context of another software, but I am unable to find it. I would like to implement a module which should manage munin-clients as well as the munin-server. Here is what I am thinking about implementing: - There are two classes: munin::client and munin::server - munin::clients'' configuration will be managed automatically.

Fix several warnings and broken links. This series was generated against linux-next, but was rebased to be applied at docs-next. It should apply cleanly on either tree. There's a git tree with all of them applied on the top of docs/docs-next at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2 Mauro Carvalho Chehab (21): ABI: sysfs-devices-system-cpu: point to

.../arch/x86/Kconfig.debug index 6791a3c97589..71c92db47c41 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -156,7 +156,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86/x86_64/boot-options.txt for more + options. See Documentation/x86/x86_64/boot-options.rst for more details. config IOMMU_LEAK diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..90d791ca1a95 10064...

.../arch/x86/Kconfig.debug index f730680dc818..59f598543203 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -156,7 +156,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86/x86_64/boot-options.txt for more + options. See Documentation/x86/x86_64/boot-options.rst for more details. config IOMMU_LEAK diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..90d791ca1a95 10064...

...f730680dc818..59f598543203 100644 > --- a/arch/x86/Kconfig.debug > +++ b/arch/x86/Kconfig.debug > @@ -156,7 +156,7 @@ config IOMMU_DEBUG > code. When you use it make sure you have a big enough > IOMMU/AGP aperture. Most of the options enabled by this can > be set more finegrained using the iommu= command line > - options. See Documentation/x86/x86_64/boot-options.txt for more > + options. See Documentation/x86/x86_64/boot-options.rst for more > details. > > config IOMMU_LEAK > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S > inde...

...f730680dc818..59f598543203 100644 > --- a/arch/x86/Kconfig.debug > +++ b/arch/x86/Kconfig.debug > @@ -156,7 +156,7 @@ config IOMMU_DEBUG > code. When you use it make sure you have a big enough > IOMMU/AGP aperture. Most of the options enabled by this can > be set more finegrained using the iommu= command line > - options. See Documentation/x86/x86_64/boot-options.txt for more > + options. See Documentation/x86/x86_64/boot-options.rst for more > details. > > config IOMMU_LEAK > diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S > inde...

.../arch/x86/Kconfig.debug index f730680dc818..59f598543203 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -156,7 +156,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86/x86_64/boot-options.txt for more + options. See Documentation/x86/x86_64/boot-options.rst for more details. config IOMMU_LEAK diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..90d791ca1a95 10064...

.../arch/x86/Kconfig.debug index f730680dc818..59f598543203 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -156,7 +156,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86/x86_64/boot-options.txt for more + options. See Documentation/x86/x86_64/boot-options.rst for more details. config IOMMU_LEAK diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..90d791ca1a95 10064...

...644 > > --- a/arch/x86/Kconfig.debug > > +++ b/arch/x86/Kconfig.debug > > @@ -156,7 +156,7 @@ config IOMMU_DEBUG > > code. When you use it make sure you have a big enough > > IOMMU/AGP aperture. Most of the options enabled by this can > > be set more finegrained using the iommu= command line > > - options. See Documentation/x86/x86_64/boot-options.txt for more > > + options. See Documentation/x86/x86_64/boot-options.rst for more > > details. > > > > config IOMMU_LEAK > > diff --git a/arch/x86/boot/header.S b/ar...

Hi all, I've been working on lguest64 and in order to do this, I had to move a lot of the i386 specific out of the way. Well, the lguest64 port is still not ready to display, but before Rusty makes too many changes I would like this in upstream so I don't have to keep repeating my changes :-) So this patch series moves lguest32 out of the way for other archs. -- Steve