On 01/22/2011 06:22 AM, Matthew Miller wrote:
> On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote:
>> The FHS is kinda old these days, and it has been a while since it was
>> last updated. The LSB added some additional rules on top of it:
>
> As long as we keep in mind that we don
On Fri, Jan 21, 2011 at 05:54:22PM +0100, Lennart Poettering wrote:
> The FHS is kinda old these days, and it has been a while since it was
> last updated. The LSB added some additional rules on top of it:
As long as we keep in mind that we don't follow the LSB at points where it
is ridiculous.
-
On Fri, 21.01.11 15:01, Richard W.M. Jones (rjo...@redhat.com) wrote:
> > If /tmp is not supposed to be used for data that is inconvenient to
> > store in memory for whatever reason, and that should be automatically
> > removed when it is not used, what _is_ it supposed to be used for?
>
> The FH
On Thu, Jan 20, 2011 at 08:37:21AM +0100, Miloslav Trmač wrote:
> Nathanael D. Noblet píše v Čt 20. 01. 2011 v 00:33 -0700:
> > On 01/19/2011 12:11 PM, Callum Lerwick wrote:
> > > On Thu, Dec 23, 2010 at 11:26 AM, drago01 wrote:
> > >> Well /tmp should be mounted tmpfs anyway (I have been doing t
Nathanael D. Noblet píše v Čt 20. 01. 2011 v 00:33 -0700:
> On 01/19/2011 12:11 PM, Callum Lerwick wrote:
> > On Thu, Dec 23, 2010 at 11:26 AM, drago01 wrote:
> >> Well /tmp should be mounted tmpfs anyway (I have been doing this for
> >> years and it is working just fine).
> >> tmp isn't a persis
On 01/19/2011 12:11 PM, Callum Lerwick wrote:
> On Thu, Dec 23, 2010 at 11:26 AM, drago01 wrote:
>> Well /tmp should be mounted tmpfs anyway (I have been doing this for
>> years and it is working just fine).
>> tmp isn't a persistent storage so it makes a lot of sense, and it is
>> *not* a dumping
On Wed, Jan 19, 2011 at 01:11:08PM -0600, Callum Lerwick wrote:
> On Thu, Dec 23, 2010 at 11:26 AM, drago01 wrote:
> > Well /tmp should be mounted tmpfs anyway (I have been doing this for
> > years and it is working just fine).
> > tmp isn't a persistent storage so it makes a lot of sense, and it
On Thu, Dec 23, 2010 at 11:26 AM, drago01 wrote:
> Well /tmp should be mounted tmpfs anyway (I have been doing this for
> years and it is working just fine).
> tmp isn't a persistent storage so it makes a lot of sense, and it is
> *not* a dumping ground for giant files (apps that try to do that ar
On Fri, 2011-01-07 at 11:46 +, Richard W.M. Jones wrote:
> On Tue, Jan 04, 2011 at 05:42:12PM -0800, Garrett Holmstrom wrote:
> > On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti wrote:
> > > What sort of attack would this enable?
> > >
> > > Wait... any unprivileged process can create sockets
On Tue, Jan 04, 2011 at 05:42:12PM -0800, Garrett Holmstrom wrote:
> On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti wrote:
> > What sort of attack would this enable?
> >
> > Wait... any unprivileged process can create sockets in the abstract
> > namespace? Uh-oh.
>
> Any unprivileged process ca
On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti wrote:
> What sort of attack would this enable?
>
> Wait... any unprivileged process can create sockets in the abstract
> namespace? Uh-oh.
Any unprivileged process can prevent you from running X on a given
display by using up the socket name that
On Wed, 2011-01-05 at 00:59 +0100, Lennart Poettering wrote:
> Well, OK, bad wording on my side. Replace "fixed" by "guessable".
What sort of attack would this enable?
Wait... any unprivileged process can create sockets in the abstract
namespace? Uh-oh.
--
// Bernie Innocenti - http://codewi
On Tue, 04.01.11 17:36, Adam Jackson (a...@redhat.com) wrote:
> On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote:
>
> > Misusing are ICE, X11, nspluginwrapper at least, since they do not use a
> > random socket name but a fixed one, hence opening the door to DoS attacks.
>
> X's socke
On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote:
> Misusing are ICE, X11, nspluginwrapper at least, since they do not use a
> random socket name but a fixed one, hence opening the door to DoS attacks.
X's socket name isn't fixed. It's a function of whatever display name
you asked for
On Mon, 03.01.11 22:12, Bernie Innocenti (ber...@codewiz.org) wrote:
> On my desktop, abstract namespace sockets are twice more popular than
> the regular ones:
>
> ber...@giskard:~$ netstat -ax | grep @ | wc -l
> 151
> ber...@giskard:~$ netstat -ax | grep -v @ | grep / | wc -l
> 73
>
> Mos
On Sat, 2010-12-25 at 19:37 +0100, Lennart Poettering wrote:
> That basically means that besides systemd itself and maybe the D-Bus
> system bus almost nobody can safely use fixed name abstract namespace
> sockets. In particular user code that uses fixed name abstract namespace
> sockets is necessa
On Mon, 03.01.11 09:54, Chris Adams (cmad...@hiwaay.net) wrote:
>
> Once upon a time, Adam Jackson said:
> > Sadly this turns out not to be the case, at least if I'm reading
> > fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime
> > and ctime are still modified on every pipe
Once upon a time, Adam Jackson said:
> Sadly this turns out not to be the case, at least if I'm reading
> fs/pipe.c correctly. O_NOATIME will turn off atime updates, but mtime
> and ctime are still modified on every pipe write, and there's no such
> thing as O_NOCMTIME even though the filesystem
On Thu, 2010-12-23 at 22:59 +0100, Lennart Poettering wrote:
> On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
> wrote:
>
> > this isn't exactly correct.
> >
> > in /dev/shm on linux we have:
> >
> > (a) unix-domain sockets for non-RT communication with the server
On Sat, 25.12.10 11:51, Casey Dahlin (cdah...@redhat.com) wrote:
> > Could you explain a bit perhaps? I'm not familiar with them... (or
> > maybe you have a url I could surf to?)
> >
> Basically, you put a \0 in front of the path when you bind the socket. So, for
> example, bind to "\0/jack/socket
On Fri, 24.12.10 16:17, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
>
> On 12/23/2010 01:52 PM, Lennart Poettering wrote:
> > On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
> > wrote:
> >> I raise this issue because "The API for /dev/shm is shm_open()"
> >
On 12/23/2010 01:52 PM, Lennart Poettering wrote:
> On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu)
> wrote:
>> I raise this issue because "The API for /dev/shm is shm_open()"
>> statement above means to me that in the future there will be no file api
>> access to a ram m
On Thu, Dec 23, 2010 at 09:11:46AM -0800, Fernando Lopez-Lezcano wrote:
> On 12/22/2010 12:56 PM, Casey Dahlin wrote:
> >On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
> >>This is from Paul Davis, the main architect of Jack (I forwarded him
> >>your post):
> >>
> >>
> >
On Mon, 20.12.10 19:16, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
> this isn't exactly correct.
>
> in /dev/shm on linux we have:
>
> (a) unix-domain sockets for non-RT communication with the server
> (b) FIFOs for RT wakeups (this could use semaphores now)
If this uses O
On Mon, 20.12.10 17:26, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
> > In other words, these are setup costs, not maintenance costs. This may
> > cause glitches in a realtime scenario to the extent that clients are
> > created and destroyed, but in general I submit that the cost of
On Mon, 20.12.10 13:07, Fernando Lopez-Lezcano (na...@ccrma.stanford.edu) wrote:
> Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the
> file api (apologies if my wording is not absolutely correct in unix
> terms) on the tmpfs filesystem that is mounted on /dev/shm for a very
On Wed, 15.12.10 08:44, John Reiser (jrei...@bitwagon.com) wrote:
> > I don't think there's a particularly good reason to use that filesystem for
> > other uses. Just mount another tmpfs elsewhere.
>
> mount() requires CAP_SYS_ADMIN and therefore an application cannot rely
> on performing mounts.
be,
> > "cleaner"
> > could be the single most important thing to improve in the entire distro.
>
> The trouble is that we can't all agree on the immeasurable benefits (but
> we can probably agree on the existence of the measurable costs), which
> is why
On Tue, 14.12.10 21:11, Nicholas Miell (nmi...@gmail.com) wrote:
> On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> > In order to make things secure we minimize what is allowd on the various
> > API file systems we mount. That includes that we set noexec and similar
> > options for the file sys
drago01 píše v Čt 23. 12. 2010 v 18:26 +0100:
> Well /tmp should be mounted tmpfs anyway (I have been doing this for
> years and it is working just fine).
> tmp isn't a persistent storage so it makes a lot of sense, and it is
> *not* a dumping ground for giant files (apps that try to do that are
>
On Tue, Dec 21, 2010 at 2:26 AM, Fernando Lopez-Lezcano
wrote:
> On 12/20/2010 02:17 PM, Adam Jackson wrote:
>> On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
>>
>>> I would like to bring to the attention of the list another current usage
>>> of the tmpfs mounted on /dev/shm in F
On Thu, 2010-12-23 at 09:11 -0800, Fernando Lopez-Lezcano wrote:
> On 12/22/2010 12:56 PM, Casey Dahlin wrote:
> > On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
> >> (a) unix-domain sockets for non-RT communication with the server
> > Perhaps these could become abstra
On 12/22/2010 12:56 PM, Casey Dahlin wrote:
> On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
>> This is from Paul Davis, the main architect of Jack (I forwarded him
>> your post):
>>
>>
>> this isn't exactly correct.
>>
>> in /dev/shm on linux we have:
>>
>> (a) u
On Mon, Dec 20, 2010 at 07:16:21PM -0800, Fernando Lopez-Lezcano wrote:
> This is from Paul Davis, the main architect of Jack (I forwarded him
> your post):
>
>
> this isn't exactly correct.
>
> in /dev/shm on linux we have:
>
> (a) unix-domain sockets for non-RT communication with the
On 12/20/2010 05:26 PM, Fernando Lopez-Lezcano wrote:
> On 12/20/2010 02:17 PM, Adam Jackson wrote:
>> On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
>>
>>> I would like to bring to the attention of the list another current usage
>>> of the tmpfs mounted on /dev/shm in Fedora pack
On 12/20/2010 02:17 PM, Adam Jackson wrote:
> On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
>
>> I would like to bring to the attention of the list another current usage
>> of the tmpfs mounted on /dev/shm in Fedora packages:
>>
>> Jack (the Jack Audio Connection Kit, jackaudio.o
On Mon, 2010-12-20 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
> I would like to bring to the attention of the list another current usage
> of the tmpfs mounted on /dev/shm in Fedora packages:
>
> Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the
> file api (apologies if
On 12/14/2010 09:37 PM, Lennart Poettering wrote:
> On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
>
>> The project is a database system that creates and dlopen()s
>> plugins on-the-fly, for better performance on ["long-running"] queries.
>> We like the speed of creat+write+close
Casey Dahlin píše v Čt 16. 12. 2010 v 15:50 -0500:
> On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
> > Especially minor changes that don't bring any measurable benefit
> > (perhaps making the system "cleaner" or making programmer's life more
> > convenient) but require time from e
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote:
> Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
> > On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> > > What you don't understand is that you are throwing away the experience
> > > and knowledge of thousands
On Thu, 2010-12-16 at 20:16 +0100, Miloslav Trmač wrote:
> Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
> > On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> > > What you don't understand is that you are throwing away the experience
> > > and knowledge of thousands of Unix
Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500:
> On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> > What you don't understand is that you are throwing away the experience
> > and knowledge of thousands of Unix system administrators. Almost of
> > all of them do not even re
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote:
> On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote:
> > Jeez. Tha's just FUD. Of course we have discussed this openly with
> > various folks. We haven't discussed this with you, Rich, personally, but
> > well, I'l
On Wed, Dec 15, 2010 at 07:17:21AM +0100, Lennart Poettering wrote:
> systemd documentation is actually pretty good and mostly
> comprehensive. Humble as I am I would even say that it is vastly
> superior to the majority of all open source projects. If you want to
> criticise us on something, pick
On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote:
> Jeez. Tha's just FUD. Of course we have discussed this openly with
> various folks. We haven't discussed this with you, Rich, personally, but
> well, I'll make a note now tht I'll DoS you now with every single
> choice we make, t
On 12/15/2010 06:40 AM, Matthew Miller wrote:
> On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
>> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
>> See the other message for the history. When something is in the file
>> system, then by default the file system APIs
On Tue, Dec 14, 2010 at 10:19:38PM -0800, John Reiser wrote:
> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
> See the other message for the history. When something is in the file
> system, then by default the file system APIs (including creat, open,
> read, write, close, exec
Lennart Poettering píše v St 15. 12. 2010 v 06:59 +0100:
> On Tue, 14.12.10 13:53, Miloslav Trmač (m...@volny.cz) wrote:
>
> > Changing the semantics of /etc/fstab without any consultation with
> > fedora-devel or even notification of Fedora that something so
> > long-standing is changing is hard
- "John Reiser" wrote:
> On 12/14/2010 07:28 PM, Lennart Poettering wrote:
>
> > In order to make things secure we minimize what is allowd on the
> various
> > API file systems we mount. That includes that we set noexec and
> similar
> > options for the file systems involved. The interface
On Tue, 14.12.10 22:19, John Reiser (jrei...@bitwagon.com) wrote:
> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
> See the other message for the history. When something is in the file
> system, then by default the file system APIs (including creat, open,
> read, write, close
On Tue, 14.12.10 18:22, Miloslav Trmač (m...@volny.cz) wrote:
> Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> > > The problem is not the technical solution. Problem is that changes of
> > > such important thing like /etc/fstab are decided without Fedora
> > > developers.
> >
> > Eh, wh
On Tue, 14.12.10 14:25, Richard W.M. Jones (rjo...@redhat.com) wrote:
>
> On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
> > We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > T
On 12/14/2010 09:37 PM, Lennart Poettering wrote:
> On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
>
>> The project is a database system that creates and dlopen()s
>> plugins on-the-fly, for better performance on ["long-running"] queries.
>> We like the speed of creat+write+clos
On Tue, 14.12.10 17:54, Paul Wouters (p...@xelerance.com) wrote:
> On Tue, 14 Dec 2010, Tomasz Torcz wrote:
>
> > Of course administrator can temporary override:
> > mount /dev/shm -o remount, nosuid
> >
> > Or even have it stick after reboot, by droping in /etc/systemd/system/
> > following uni
On Tue, 14.12.10 08:08, Chris Adams (cmad...@hiwaay.net) wrote:
>
> Once upon a time, Tomasz Torcz said:
> > We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those all directories are mount
On Tue, 14.12.10 13:53, Miloslav Trmač (m...@volny.cz) wrote:
> Changing the semantics of /etc/fstab without any consultation with
> fedora-devel or even notification of Fedora that something so
> long-standing is changing is hardly constructive either.
>
> I can happily live with "systemd is a n
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
> The project is a database system that creates and dlopen()s
> plugins on-the-fly, for better performance on ["long-running"] queries.
> We like the speed of creat+write+close+open+read+mmap on /dev/shm.
> If /dev/shm and /tmp both
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open()
On 12/14/2010 21:28, Lennart Poettering wrote:
> On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:
>
> Thanks, Bill, for replying in so much detail.
>
> Here are a few other points:
>
>> - systemd mounts API filesystems without them needing to be in
>>/etc/fstab. This is for a
On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:
Thanks, Bill, for replying in so much detail.
Here are a few other points:
> - systemd mounts API filesystems without them needing to be in
> /etc/fstab. This is for a variety of reasons - having every system
> installer hav
On Tue, 2010-12-14 at 17:54 -0500, Paul Wouters wrote:
> On Tue, 14 Dec 2010, Tomasz Torcz wrote:
>
> > Of course administrator can temporary override:
> > mount /dev/shm -o remount, nosuid
> >
> > Or even have it stick after reboot, by droping in /etc/systemd/system/
> > following unit definitio
On Tue, 14 Dec 2010, Bill Nottingham wrote:
> It probably should be relnoted, sure.
A relnote is not a substitute for proper documentation, logging and man pages.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
> Of course administrator can temporary override:
> mount /dev/shm -o remount, nosuid
>
> Or even have it stick after reboot, by droping in /etc/systemd/system/
> following unit definition¹:
No.
You either follow what is in /etc/fstab, or you disallow it
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
> On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
> > We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those a
On Tue, 2010-12-14 at 13:48 -0500, Bill Nottingham wrote:
> And again, listing things like /sys in fstab can just give the
> uninitiated the idea that it's something they can change... it's *not*
> a configuration setting.
But I want to mount my /sys over nfs! What do you mean, it's not going
to
Miloslav Trmač (m...@volny.cz) said:
> So the design was to
> 1) change the setting in the C reimplementation
The design was to pick a default... it's actually been that way since the
initial implementation and that *is* the default on some other distributions.
It probably should be relnoted, su
Chris Adams (cmad...@hiwaay.net) said:
> I've seen this said at least a couple of times. In what way is it
> "wasteful"? On most systems, /etc/fstab is going to be less than one
> filesystem block anyway, so there is absolutely zero "waste" going on.
>
> If "waste" of a few dozen bytes is now a
Jesse Keating píše v Út 14. 12. 2010 v 09:47 -0800:
> On 12/14/10 9:22 AM, Miloslav Trmač wrote:
> > Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> >>> The problem is not the technical solution. Problem is that changes of
> >>> such important thing like /etc/fstab are decided without Fedor
Once upon a time, Bill Nottingham said:
> having every system
> installer have to write /proc, /sys, and so on is pretty wasteful.
I've seen this said at least a couple of times. In what way is it
"wasteful"? On most systems, /etc/fstab is going to be less than one
filesystem block anyway,
On 12/14/10 9:22 AM, Miloslav Trmač wrote:
> Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
>>> The problem is not the technical solution. Problem is that changes of
>>> such important thing like /etc/fstab are decided without Fedora developers.
>>
>> Eh, what? It's a change to how API files
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> > The problem is not the technical solution. Problem is that changes of
> > such important thing like /etc/fstab are decided without Fedora developers.
>
> Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
> mounted. When
Marcela Mašláňová (mmasl...@redhat.com) said:
> >>> That's not a very constructive wording. Filing a bug showing your use-case
> >>> would be helpful.
I'd like to restate this point. It's rather disappointing that so many
people have decided to skip over this, and prefer to instead complain,
insi
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
> I think it's very reasonable to want to edit /etc/fstab to change the
> default mount options of these filesystems. Suppose that /dev/shm
> defaults to allowing suid and exec. At some point in the future a
> security problem is
On Tue, 14 Dec 2010, Tomasz Torcz wrote:
> We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here. Why pollute fs
On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
> We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down
Marcela Mašláňová píše v Út 14. 12. 2010 v 14:55 +0100:
> On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
> > On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
> >> Changing the semantics of /etc/fstab without any consultation with
> >> fedora-devel or even notification of Fedora that som
Once upon a time, Tomasz Torcz said:
> We saw it includes /dev, /dev/shm etc. Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here. Why pollute fstab
On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
> On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
>> Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
>>> On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
>>> wrote:
> the MS_NOEXEC flags is in private syst
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
> Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
> > On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > > the MS_NOEXEC flags is in private systemd fstab, see
> > > > systemd/src/mount-setu
I will be away from 14 December 2010 to 7 January 2011. For Translate.org.za
and ANLoc queries, please contact the office: +2712 460 1095 or info AT
translate.org.za.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
> On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > > the MS_NOEXEC flags is in private systemd fstab, see
> > > systemd/src/mount-setup.c:
> > You're not kidding. Could the author of this code (I'm guessing..
On Mon, Dec 13, 2010 at 09:47:49AM -0600, Garrett Holmstrom wrote:
> If systemd is going to ignore fstab entries, could we please have the
> fstab file on newly-installed systems replace the entries that would be
> ignored with commentary that explains which filesystems will be ignored?
>
> That
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > the MS_NOEXEC flags is in private systemd fstab, see
> > systemd/src/mount-setup.c:
> You're not kidding. Could the author of this code (I'm guessing...
> Lennart?) please explain this extremely bright idea of hard-
Hi,
On Monday, 13 December 2010 at 14:37, Karel Zak wrote:
> On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
> > How did /dev/shm get noexec in Fedora 15 rawhide?
> >$ grep /dev/shm /proc/mounts
> >tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
> >$ grep
Karel Zak wrote:
> > As a site administrator, how can I change the default to omit 'noexec'?
>
> mount -o remount,exec ?
That's not really changing the default.
David
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 12/13/2010 7:37, Karel Zak wrote:
> On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
>> How did /dev/shm get noexec in Fedora 15 rawhide?
>> $ grep /dev/shm /proc/mounts
>> tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
>> $ grep -srl noexec /etc
>>
On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
> How did /dev/shm get noexec in Fedora 15 rawhide?
>$ grep /dev/shm /proc/mounts
>tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
>$ grep -srl noexec /etc
>/etc/alternatives/ld
>/etc/fstab ## deriv
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl noexec /etc
/etc/alternatives/ld
/etc/fstab ## derived from /proc/mounts
/etc/mtab## derived from /proc/mounts
This i
89 matches
Mail list logo
